In the high-stakes world of digital infrastructure, speed isn’t just a metric — it’s currency. At Google Cloud Next ‘26 we announced the Bigtable in-memory tier, a breakthrough for our fully managed cloud database service that delivers:
-
Sub-millisecond read latency for time-sensitive data
-
~10x higher point read throughput per dollar, dramatically reducing TCO
-
Hotspot resistance, supporting up to 120,000 queries per second on a single row without breaking a sweat.
For more information see Bigtable performance documentation. Now, let’s look at the impact Bigtable in-memory tier can have on your workload performance and operational processes.
The cache-miss nightmare: A familiar story
Imagine it’s 2:00 AM. Your promotional campaign just went viral, and traffic is spiking. Your database architecture, meanwhile, is a house of cards: a primary database struggling to keep up and a separate caching layer acting as a shield.
Suddenly, you’re hit with a hot key problem: everyone is trying to access the same viral content. Your cache node saturates. You’re forced to upgrade to larger nodes or add read replicas. You and your team are exhausted. Not only are you managing two different systems, maintaining a complex cache-aside logic (and praying the data in the cache stays in sync with the database), but you also need to respond to the actual incident. To do so, you overprovision CPU to handle the peak, and add more RAM so that everything fits in memory, as well as to avoid cache-aside complexity. Now you’re paying premium prices for warm data that doesn’t actually need to be in memory. And while your hypothetical throughput-per-dollar looks great on paper, 90% of your resources sit idle most of the time.
Enter Bigtable’s in-memory tier
The Bigtable in-memory tier ends this cycle. By bringing data tiering across RAM, SSD, and HDD into a single, unified service with a hybrid storage architecture, we’ve removed the middleman.
The result? You get the raw throughput and speed of a cache with the durability and scale that Bigtable was designed for. When that viral spike hits, Bigtable automatically moves hot rows into memory to handle the load. No CPU spikes, no performance degradation. If the traffic grows, so does your Bigtable cluster by giving you more in-memory read capacity. You no longer need to overpay for idle RAM or cache nodes; Bigtable intelligently manages your data, keeping only the hot data in memory and ensuring data consistency between in-memory tier and SSD storage.
The TCO benefits are tangible, but maybe the most important part is the peace of mind that comes with it — and that’s priceless.
A peek behind the curtain
Almost every database server uses memory to give CPU fast access to latency-sensitive, frequently accessed data such as indexes and Bloom filters. You might be wondering, what makes this announcement different?
The secret lies in Remote Direct Memory Access (RDMA), a high-performance networking technology that allows computers to transfer data directly from one machine’s memory to another without involving either the system’s operating system or CPU. Our architecture uses RDMA to provide a high-speed, direct path to server memory, and as a result, throughput and latency of in-memory tier isn’t bound by server CPU, translating to impressive benefits. Much like Data Boost enables direct disk access for heavy workloads such as ML training, RDMA provides high-speed, direct memory access for real-time processing.
Imagine you’re running a popular social media site where 98% of users have fewer than 250 followers, while your most popular users have over 100 million. 60% of users post less than once a week, and the top 10% of users generate 80% of the content. And while a typical post receives 500 impressions, popular ones receive tens of millions.
To efficiently address this use case you will want data tiering that will likely look like this:
-
Memory: Content from profiles of users with large followings
-
SSD: Recent content, active user profiles
-
HDD: Older content, inactive user profiles
Luckily this is very easy to accomplish in Bigtable. Simply enable in-memory for your cluster and use a memory-enabled application profile when issuing your database requests to automatically manage the hot data lifecycle. You can also set an age-based policy to tier cold data to infrequent access. With this setup, when a piece of content is read, it gets promoted to the memory tier from persistent storage and stays there until it is evicted to make room for more recently read items. It is hands-free; even if a post from 5 years ago makes a viral comeback all of a sudden, you don’t have to worry about it.
But let’s say you want more fine-grained control of what you cache. You have a list of popular content creators and want to limit memory usage to only that small subset of their posts. Simply route the traffic for those users via the memory-enabled app profile, and for the rest of the content use an app profile that isn’t memory-enabled.
The cache-miss nightmare, revisited
Let’s rewind and replay our cache-miss scenario, but with Bigtable’s in-memory tier enabled. It’s 2:00 AM Sunday morning. Your promotional campaign just went viral, and traffic is spiking, you need to serve an additional 80K reads per second for the next hour. You don’t get paged. You wake up at 11 AM to the sound of birds chirping and enjoy a peaceful breakfast. It’s a beautiful day. The only sign that traffic spiked between 2-3 AM is that your bill shows an extra $0.40 charge.
Power laws govern distribution of requests for applications in a wide range of industries so scenarios like this are not limited to social media. For example, stock exchanges trade several thousands of securities but the top 30 most active stocks typically represent more than 40% of the total daily trading volume. At the same time, the most recent data points (last trade, ask/bid price) are requested frequently with an expectation of low latency responses, while historical data is accessed much less frequently, and has a rather forgiving latency budget. Let’s break down this example into Bigtable data tiers:
-
Memory: Most recent price of securities for most sought out stocks
-
SSD: Recent history, aggregated metrics (hourly, daily, monthly etc.)
-
HDD: Older data, raw events like individual trades
The list of possible use cases for this capability is long. Automated trading systems access latest prices from memory, while retail investors build their candlestick charts from data on SSD, and quants access historical data on HDD using Data Boost to backtest their models. All in one database, without interfering with each other. You can replace financial time series with telemetry data, sensor networks, digital twins and the story wouldn’t be much different.
Nor does using Bigtable’s in-memory tier interfere with other enterprise features like high availability, scaling, auditing, governance, and access controls, which typically introduce significant overhead. Achieving sub-millisecond latency despite these enterprise requirements is extremely impressive. By optimizing our clients and network, we’ve also successfully reduced p50 SSD latencies to below 2 milliseconds.
Get started with Bigtable Enterprise Plus
The Bigtable in-memory tier is available exclusively as part of the new Bigtable Enterprise Plus edition, which offers many additional features and is designed for organizations that demand the highest levels of performance, and management efficiency.
Elevate your stack to Bigtable Enterprise Plus and in-memory capabilities today so you can stop managing infrastructure and start building the future!
Learn more
-
Learn more about Bigtable Enterprise Plus edition and its capabilities beyond the in-memory tier. Try it out by heading over to Google Cloud console and creating new clusters upgrading existing ones.
-
If you’re new to Bigtable, you can now experience Google’s pioneering NoSQL database with the new Bigtable Free Trial. Get a dedicated Enterprise Edition node, 500GB storage, and a guided tour of Bigtable.
- For more detailed information on getting started, technical specifications, and regional availability, visit the official Bigtable product page.
