Forem: Aerospike

Introducing Aerospike Graph Database 3.0: Faster, simpler, and built for the terabyte scale era

Aerospike — Tue, 29 Jul 2025 20:49:32 +0000

Discover Aerospike Graph 3.0, built for billion-scale speed, ease, and cost-efficiency in fraud, identity, and personalization graph workloads.

Author: Ishaan Biswas, Director of Product Management - Graph

Today, we’re announcing the release of Aerospike Graph Database 3.0, bringing major improvements across the three dimensions that matter most: developer ease with multi-property and native datetime support, 10x faster ingest performance, and up to 50% better cost efficiency through reduced storage footprint. Built for teams managing the most demanding graph workloads in identity resolution, fraud prevention, and real-time personalization, Aerospike Graph Database 3.0 is our biggest step forward in making high-scale, graph data fast, accessible, and affordable.

Easier to develop

Aerospike Graph Database 3.0 introduces two key capabilities that make modeling and querying graph data more natural and powerful:

Multi-property support

Vertices can now store multiple values under the same property key. This simplifies how you can model complex signal relationships, such as multiple timestamps, scores, or segments, without complex workarounds or nested structures.

Example: Store multiple tags on a user vertex
g.addV('User') .property('T.id', 'user-123') .property(VertexProperty.Cardinality.list, 'tag', 'frequent-buyer') .property(VertexProperty.Cardinality.list, 'tag', 'mobile-user') .property(VertexProperty.Cardinality.list, 'tag', 'high-LTV')

Query all tags for the user
g.V().has('id', 'user-123').values('tag') // Output: ['frequent-buyer', 'mobile-user', 'high-LTV']

Or query Users with a tag
.V().has(“tag”, “high-LTV”) // Output: [user-123]

This is especially useful in AdTech, identity graphs, fraud, and personalization graphs, where entities accumulate multiple attributes over time.

Native Datetime support

Timestamps are now supported as a first-class property type. You can store, filter, and compare temporal data directly with no need to convert or encode datetime fields manually.

Example: Add a timestamp to a session vertex

g.addV('Session') .property('id', 'sessionid-123456') .property('startedAt', datetime('2025-07-08T14:22:00Z'))
Query sessions that started in the last 24 hours

g.V().hasLabel('Session') .has('startedAt', gt(datetime('2025-07-07T14:22:00Z')))

These capabilities make the platform more expressive and developer-friendly, especially for time-based and signal-rich domains.

Faster to load

Aerospike Graph 3.0 ships with a re-architected bulk loader that dramatically reduces ingest time, especially at large scale.

In production-scale benchmark tests, we loaded a terabyte of data in under three hours, down from over 32 hours with version 2.6. That’s a >10x performance gain, with the same infrastructure.

This performance unlocks faster iteration and experimentation cycles, allowing teams to load large datasets quickly, validate changes, and refresh data frequently, without needing to scale up infrastructure or wait for a long time to see the results of their changes.

Cheaper to run

Aerospike Graph Database 3.0 also delivers substantial gains in storage efficiency and overall total cost of ownership.

Improvements to on-disk data layout reduce storage footprint by up to 50%, which means fewer nodes are required to store the same data. This directly reduces cluster size and infrastructure costs.

Operate a terabyte-scale graph for a fraction of the cost of any other graph database
Enjoy predictable cost scaling, with $/GB dropping as data volume increases

Combined with Aerospike’s Hybrid Memory Architecture and the ability to scale compute and storage independently via the Aerospike Graph Service, Aerospike Graph offers the most cost-efficient ways to run high-performance graph workloads, without the constraints of RAM-bound architectures.

Get started

Aerospike Graph Database 3.0 is:

Easier to build on - with multi-property vertex support and native datetime types
Faster to load - with >10x ingest speed for billion-scale datasets
Cheaper to run - with smaller clusters, lower storage footprint, and reduced total cost of ownership at scale

If you’re solving large-scale graph problems that power real-time decisions, Aerospike Graph Database 3.0 is built for you.

→ [Read the release notes]

How Criteo scaled 290M QPS and cut its server footprint by 78%

Aerospike — Thu, 24 Jul 2025 21:36:16 +0000

Author: Steve Tuohy - Director of Product Marketing

Discover how Criteo scaled to 290M queries-per-second, swapped Couchbase + Memcached for Aerospike, cut servers by 78%, and kept sub-ms latency.

Criteo serves more than 700 million users daily with personalized ads, processing billions of events in milliseconds. At its peak, Criteo’s infrastructure handles 290 million key-value queries per second (QPS).

Until recently, this real-time engine ran on a complex stack of Couchbase and Memcached, propped up by custom C clients and costly operational overhead. Performance during rebalancing was fragile, cache warming required manual traffic shaping, and RAM costs were high.

But when Criteo rebuilt its stack using Aerospike’s patented Hybrid Memory Architecture (HMA), the company consolidated two systems into one, simplified operations, and cut its server footprint by 78%, all while maintaining sub-millisecond latency at global scale.

Maintaining real-time access at AdTech scale

Criteo isn’t just serving banner ads. It runs real-time auctions on the open web, responding to 20 million bid requests per second. Each request requires dozens of micro-decisions: audience scoring, campaign pacing, frequency caps, and more.

"Our key-value storage system peaks at about 290 million queries per second, which is fairly large,” said Maxime Brugidou, vice president of engineering, Criteo.

All of that happens in under 100 ms. The stack is written in C, runs on premises across 40,000 servers and seven data centers, and operates through Kubernetes and Apache Mesos.

The demands on storage? Sub-millisecond latency, no downtime during rebalancing or upgrades, and a globally distributed footprint.

The legacy stack: Couchbase + Memcached + custom C logic

Before adopting Aerospike, Criteo’s real-time infrastructure relied on Couchbase for the data, with Memcached as a caching layer. A custom-built C client orchestrated dual writes and replication between tiers, and maintained consistency between the two systems. “It was very difficult to make it perform well during rebalancing or maintenance,” Brugidou said. “It was quite unstable.”

Operationally, this design required careful tuning and careful rerouting of traffic. Any node failure or rebalance event degraded performance and had to be dealt with.

The turning point: Aerospike’s Hybrid Memory Architecture (HMA)

Aerospike’s HMA changed the game. It decouples index storage from data storage:

Indexes stay in RAM for fast access.
Data lives on SSDs, such as NVMe drives, in Criteo's case.

This model gave Criteo Memcached-level low latency with the durability of disk and let the company collapse its architecture from two databases into one. "There was this nice design with the index being in memory and the data on disk,” Brugidou said. “It allowed for really good tradeoffs."

By keeping indexes in memory and serving records from fast SSDs, Aerospike hit sub-millisecond reads without needing RAM to hold entire datasets. For Criteo, this not only simplified its system design but also saved money.

"Aerospike combined with NVMe disks… we had basically Memcached performance except that we were using persistent storage,” Brugidou said. “That was quite impressive…Aerospike was able to keep reading steadily at high throughput and very, very low latency despite all the mess we were putting on the servers."

Kubernetes-native deployment: From custom scripts to automated ops

Criteo replaced both Couchbase and Memcached with Aerospike. The company removed its custom client drivers, adopted Aerospike’s native C client, and rolled out a Kubernetes-native deployment on-prem with the Aerospike Kubernetes Operator.

Operational wins included:

Automatic node recovery and rebalancing via Kubernetes
Eliminating the custom C client, reducing complexity

Multi-bin optimization: Collapsing data models for performance

Aerospike’s multi-bin optimization simplified things even more. Criteo merged multiple datasets into one namespace, which helped reduce index memory usage and improve access efficiency. "You can write to some bins very easily and read all the bins at once. You only pay for indexing once in memory. That was quite a significant win," Brugidou said.

Aerospike also made rebalancing and node failure recovery seamless to the team. "We do that transparently,” Brugidou said. Aerospike is able to rebalance so easily… This is fully automated and very easy to do with the Kubernetes Operator.” Multi-bin optimization also meant:

Reduced index memory usage by avoiding duplication
Faster lookups, because all bins could be read in one fetch

This move simplified things even more, aligning with Criteo's infrastructure-as-code strategy and reducing human intervention during failure recovery.

Infrastructure impact: 78% server reduction and lower carbon footprint

By replacing Couchbase and Memcached with Aerospike, Criteo reduced server count from more than 3,000 to just 720. This meant:

Lowered total RAM and disk footprint
Reduced power consumption and cooling

Began running on 100% renewable energy in 2022, accomplished with the purchase of certificates and relocation of data centers to more sustainable locations.

“We’re doing many more queries for less electricity in the end. Way less,” said Brugidou. This migration supports Criteo’s science-based climate target to reduce electricity consumption by 42% by 2030.

Lessons learned: Performance tuning, not over-engineering

Despite the performance of the new system, Criteo didn’t jump straight to exotic optimizations. Instead, it prioritized simplicity:

Avoided pre-loading datasets in RAM
Let Aerospike handle replication and rebalancing
Tuned bin and namespace configs incrementally based on workload metrics

Brugidou emphasized that consistency and throughput remained stable even under stress tests, without resorting to low-level tuning.

Takeaway: Scaling real-time systems without scaling costs

By replacing a brittle, multi-tiered stack with Aerospike’s real-time engine, Criteo gained both technical efficiency and reduced costs. It consolidated two systems into one, improved performance, reduced latency, and slashed infrastructure overhead, without sacrificing resiliency or scale.

For teams building real-time systems with massive QPS and tight SLAs, Criteo’s experience shows what becomes possible with the right storage architecture.

With Aerospike, Criteo:

Consolidated two systems into one
Maintained sub-millisecond latency
Reduced infrastructure costs and energy use
Gained reliability through automation

Want to learn more? Check out the webinar replay or talk to our team about what real-time data infrastructure can do for you.

Aerospike Rust client preview: Introducing a native integration for high-performance systems

Aerospike — Thu, 17 Jul 2025 17:18:30 +0000

Brian Porter - Principal Product Manager, Database

Explore Aerospike's new official Rust client, built for memory-safe, low-latency systems. See features, roadmap, and how to start integrating today.
_

Developers building high-throughput, low-latency applications in Rust now have access to a high-performance client developed and maintained by Aerospike with the preview release of its official Rust client. This milestone represents more than just a new client library; it marks a shift from a community-supported project to one that business leaders can feel safe adopting.

Driven by increasing demand from our developer community and the rapid adoption of Rust for performance-critical, memory-safe systems, this release enables Rust developers to integrate Aerospike into their applications, all while preserving the consistency, speed, and reliability that define our platform.

Why Rust: Strategic alignment with developer needs

Rust is increasingly used across industries such as finance, telecommunications, cloud infrastructure, and embedded systems. It has become the preferred choice for performance-critical systems development. Organizations such as Amazon, Cloudflare, and Discord have adopted Rust to build reliable infrastructure and eliminate classes of memory-related bugs that commonly affect C/C++-based software.

Its popularity is driven by a combination of performance and reliability characteristics that are a natural fit for Aerospike applications:

No garbage collection: Rust’s lack of a garbage collector helps eliminate latency outliers, a key requirement for real-time systems.
Compile-time memory safety: Rust’s memory safety model reduces crash potential by catching common security vulnerabilities at compile time.
Safe concurrency support: Rust prevents data races by enforcing thread safety at compile time, helping high-concurrency applications scale better.
Modern tooling and developer experience: Over 100,000 Rust crates exist today, providing straightforward integration with Kafka, gRPC, observability tools, and more, forming a mature ecosystem.

Rust client capabilities

Rust Preview highlights include:

Execution models:

Async-first: Built for non-blocking IO, powered by Tokio by default, with optional support for async-std
Sync support: Blocking APIs available using a sync sub-crate for flexibility in legacy or mixed environments

Advanced data operations:

Batch protocol: Full support for read, write, delete, and UDF operations through the new BatchOperation API
New query/scan support: Implements updated query protocols for improved consistency and performance, allowing pagination and limiting the number of returned records

Policy and expression enhancements:

Replica policies: Includes support for Replica, including PreferRack policy
Policy additions: New fields such as allow_inline_ssd, respond_all_keys in BatchPolicy, read_touch_ttl, and QueryDuration in QueryPolicy
Rate limiting: Supports records_per_second for scan/query throttling

Data model improvements:

Type support: Adds support for boolean particle type
New data constructs: Returns types such as Exists, OrderedMap, and UnorderedMap, now supported for CDT reads
Value conversions: Implements TryFromAerospike::Value for type interoperability
Infinity and wildcard: Supports Infinity, Wildcard, and corresponding expression builders expressions::infinity() and expressions::wildcard()
Size expressions: Adds expressions::record_size() and expressions::memory_size() for granular control

Take a look at the changelog for more details.

The client has been built from the ground up to integrate easily with today’s Rust frameworks and async runtimes. Support for the Tokio async runtime, standard Rust crates, and idiomatic usage patterns are all part of the design.

Release timeline

The client is currently available as a preview release, with support for foundational operations. The general availability (GA) release is planned for later in 2025 and will include:

Full feature parity with other official Aerospike clients (e.g., Go, C#, Java)
Community feedback-driven improvements

The preview release is available on GitHub, and we encourage developers to experiment, provide feedback, and report issues.

Designed for the community
Aerospike developed this client because we listened to our developer community. Requests for async support, tighter performance tuning, and alignment with Rust’s ecosystem have been recurring themes in our forums and GitHub discussions. The new client is a direct response to that input.

By releasing this client under an open license and hosting it on GitHub, we aim to foster ongoing community engagement. Contributions, feature requests, and feedback will help shape the GA version and future enhancements.

Get started

Start working with the preview client today by going to the Installation section of the v2 branch of the Rust client repo.