2026-01-29 19:00:05
An in-depth look at database and cache internals, and the tradeoffs in each.
ScyllaDB would like to publicly acknowledge dormando (Memcached maintainer) and Danny Kopping for their contributions to this project, as well as thank them for their support and patience.
Engineers behind ScyllaDB – the database for predictable performance at scale – joined forces with Memcached maintainer dormando to compare both technologies head-to-head, in a collaborative vendor-neutral way.
The results reveal that:
This document explains our motivation for these tests, provides a summary of the tested scenarios and results, then presents recommendations for anyone who might be deciding between ScyllaDB and Memcached. Along the way, we analyze the architectural differences behind these two solutions and discuss the tradeoffs involved in each.
There’s also a detailed Gitbook for this project, with a more extensive look at the tests and results and links to the specific configurations you can use to perform the tests yourself.
\
:::tip Bonus: dormando and I recently discussed this project at P99 CONF, a highly technical conference on performance and low latency engineering.
:::
\
First and foremost, ScyllaDB invested lots of time and engineering resources optimizing our database to deliver predictable low latencies for real-time data-intensive applications. ScyllaDB’s shard-per-core, shared-nothing architecture, userspace I/O scheduler and internal cache implementation (fully bypassing the Linux page cache) are some notable examples of such optimizations.
Second: performance converges over time. In-memory caches have been (for a long time) regarded as one of the fastest infrastructure components around. Yet, it’s been a few years now since caching solutions started to look into the realm of flash disks. These initiatives obviously pose an interesting question: If an in-memory cache can rely on flash storage, then why can’t a persistent database also work as a cache?
Third: We previously discussed 7 Reasons Not to Put a Cache in Front of Your Database and recently explored how specific teams have successfully replaced their caches with ScyllaDB.
Fourth: At last year’s P99 CONF, Danny Kopping gave us an enlightening talk, Cache Me If You Can, where he explained how Memcached Extstore helped Grafana Labs scale their cache footprint 42x while driving down costs.
And finally, despite the (valid) criticism that performance benchmarks receive, they still play an important role in driving innovation. Benchmarks are a useful resource for engineers seeking in-house optimization opportunities.
Now, on to the comparison.
\
Tests were carried out using the following AWS instance types:
All instances can deliver up to 25Gbps of network bandwidth. Keep in mind that specially during tests maxing out the promised Network Capacity, we noticed throttling shrinking down the bandwidth down to the instances’ baseline capacity.
To overcome potential bottlenecks, the following optimizations and settings were applied:
For Memcached loaders, we used mcshredder, part of memcached’s official testing suite. The applicable stressing profiles are in the fee-mendes/shredders GitHub repository.
For ScyllaDB, we used cassandra-stress, as shipped with ScyllaDB, and specified comparable workloads as the ones used for Memcached.
The following is a summary of the tests we conducted and their results. If you want a more detailed description and analysis, go to the extended writeup of this project.
The more items you can fit into RAM, the better your chance of getting cache hits. More cache hits result in significantly faster access than going to disk. Ultimately, that improves latency.
This project began by measuring how many items we could store to each datastore. Throughout our tests, the key was between 4 to 12 bytes (key0 .. keyN) for Memcached, and 12 bytes for ScyllaDB. The value was fixed to 1000 bytes.
Memcached stored roughly 101M items until eviction started. It’s memory efficient. Out of Memcached’s 114G assigned memory, this is approximately 101G worth of values, without considering the key size and other flags:
\
ScyllaDB stored between 60 to 61M items before evictions started. This is no surprise, given that its protocol requires more data to be stored as part of a write (such as the write timestamp since epoch, row liveness, etc). ScyllaDB also persists data to disk as you go, which means that Bloom Filters (and optionally Indexes) need to be stored in memory for subsequent disk lookups.
\
Takeaways
\
The ideal (though unrealistic) workload for a cache is one where all the data fits in RAM – so that reads don’t require disk accesses and no evictions or misses occur. Both ScyllaDB and Memcached employ LRU (Least Recently Used) logic for freeing up memory: When the system runs under pressure, items get evicted from the LRU’s tail; these are typically the least active items.
Taking evictions and cache misses out of the picture helps measure and set a performance baseline for both datastores. It places the focus on what matters most for these kinds of workloads: read throughput and request latency.
In this test, we first warmed up both stores with the same payload sizes used during the previous test. Then, we initiated reads against their respective ranges for 30 minutes.
Memcached achieved an impressive 3 Million Gets per second, fully maximizing AWS NIC bandwidth (25 Gbps)!
Memcached kept a steady 3M rps, fully maximizing the NIC throughput
The parsed results show that p99.999 responses completed below 1ms:
stat: cmd_get : \n Total Ops: 5503513496 \n Rate: 3060908/s \n === timer mg === \n 1-10us 0 0.000% \n 10-99us 343504394 6.238% \n 100-999us 5163057634 93.762% \n 1-2ms 11500 0.00021%
To read more rows in ScyllaDB, we needed to devise a better data model for client requests due to protocol characteristics (in particular, no pipelining). With a clustering key, we could fully maximize ScyllaDB’s cache, resulting in a significant improvement in the number of cached rows. We ingested 5M partitions, each with 16 clustering keys, for a total of 80M cached rows.
As a result, the number of records within the cache significantly improved compared to the key-value numbers shown previously.
As dormando correctly pointed out (thanks!), this configuration is significantly different than the previous Memcached set-up. While the Memcached workload always hits an individual key-value pair, a single request in ScyllaDB results in several rows being returned. Notably, the same results could be achieved using Memcached by feeding the entire payload as the value under a single key, with the results scaling accordingly.
We explained the reasons for these changes in the detailed writeup. There, we covered characteristics of the CQL protocol (such as the per-item overhead [compared to memcached] and no support for pipelining) which make wide-partitions more efficient on ScyllaDB than single-key fetches.
With these adjustments, our loaders ran a total of 187K read ops/second over 30 minutes. Each operation resulted in 16 rows getting retrieved.
Similarly to memcached, ScyllaDB also maximized the NIC throughput. It served roughly 3M rows/second solely from in-memory data:
\
\ ScyllaDB exposes server-side latency information, which is useful for analyzing latency without the network. During the test, ScyllaDB’s server-side p99 latency remained within 1ms bounds:
The client-side percentiles are, unsurprisingly, higher than the server-side latency with a read P99 of 0.9ms.
Takeaways
\
Measuring flash storage performance introduces its own set of challenges, which makes it almost impossible to fully characterize a given workload realistically.
For disk-related tests, we decided to measure the most pessimistic situation: Compare both solutions serving data (mostly) from block storage, knowing that:
The Extstore wiki page provides extensive detail into the solution’s inner workings. At a high-level, it allows memcached to keep its hash table and keys in memory, but store values onto external storage.
During our tests, we populated memcached with 1.25B items with a value size of 1KB and a keysize of up to 14 bytes:
\
With Extstore, we stored around 11X the number of items compared to the previous in-memory workload until evictions started to kick in (as shown in the right hand panel in the image above). Even though 11X is an already impressive number, the total data stored on flash was only 1.25TB out of the total 3.5TB provided by the AWS instance.
For the actual performance tests, we stressed Extstore against item sizes of 1KB and 8KB. The table below summarizes the results:
| Test Type | Items per GET | Payload Size | IO Threads | GET Rate | P99 | |----|----|----|----|----|----| | perfrunmetagetpipe | 16 | 1KB | 32 | 188K/s | 4~5 ms | | perfrunmetaget | 1 | 1KB | 32 | 182K/s | perfrunmetagetpipe | 16 | 1KB | 64 | 261K/s | 5~6 ms | | perfrunmetaget | 1 | 1KB | 64 | 256K/s | 1~2ms | | perfrunmetagetpipe | 16 | 8KB | 16 | 92K/s | 5~6 ms | | perfrunmetaget | 1 | 8KB | 16 | 90K/s | perfrunmetagetpipe | 16 | 8KB | 32 | 110K/s | 3~4 ms | | perfrunmetaget | 1 | 8KB | 32 | 105K/s | <1ms |
We populated ScyllaDB with the same number of items as used for memcached. Although ScyllaDB showed higher GET rates than memcached, it did so under slightly higher tail latencies compared to memcached’s non-pipelining workloads. This is summarized below:
| Test Type | Items per GET | Payload Size | GET Rate | Server-side P99 | Client-side P99 | |----|----|----|----|----|----| | 1KB Read | 1 | 1KB | 268.8K/s | 2ms | 2.4ms | | 8KB Read | 1 | 8KB | 156.8K/s | 1.54ms | 1.9ms |
\
Following our previous Disk results, we then compared both solutions in a read-mostly workload targeting the same throughput (250K ops/sec). The workload in question is a slight modification of memcached’s ‘basic’ test for Extstore, with 10% random overwrites. It is considered a “semi-worst case scenario.”.
Memcached achieved a rate of slightly under 249K during the test. Although the write rates remained steady during the duration of the test, we observed that reads fluctuated slightly throughout the run:
We also observed slightly high extstoreioqueue metrics despite the lowered read ratios, but latencies still remained low. These results are summarized below:
| Operation | IO Threads | Rate | P99 Latency | |----|----|----|----| | cmdget | 64 | 224K/s | 1~2 ms | | cmdset | 64 | 24.8K/s | <1ms |
The ScyllaDB test was run using 2 loaders, each with half of the target rate. Even though ScyllaDB achieved a slightly higher throughput (259.5K), the write latencies were kept low throughout the run and the read latencies were higher (similarly as with memcached):
The table below summarizes the client-side run results across the two loaders:
| Loader | Rate | Write P99 | Read P99 | |----|----|----|----| | loader1 | 124.9K/s | 1.4ms | 2.6 ms | | loader2 | 124.6K/s | 1.3ms | 2.6 ms |
Read a more detailed analysis in the Gitbook for this project
\
Both memcached and ScyllaDB managed to maximize the underlying hardware utilization across all tests and keep latencies predictably low. So which one should you pick? The real answer: It depends.
If your existing workload can accommodate a simple key-value model and it benefits from pipelining, then memcached should be more suitable to your needs. On the other hand, if the workload requires support for complex data models, then ScyllaDB is likely a better fit.
Another reason for sticking with Memcached: it easily delivers traffic far beyond what a NIC can sustain. In fact, in this Hacker News thread, dormando mentioned that he could scale it up past 55 million read ops/sec for a considerably larger server. Given that, you could make use of smaller and/or cheaper instance types to sustain a similar workload, provided the available memory and disk footprint suffice your workload needs.
\ A different angle to consider is the data set size. Even though Extstore provides great cost savings by allowing you to store items beyond RAM, there’s a limit to how many keys can fit per GB of memory. Workloads with very small items should observe smaller gains compared to those with larger items. That’s not the case with ScyllaDB, which allows you to store billions of items irrespective of their sizes.
It’s also important to consider whether data persistence is required. If it is, then running ScyllaDB as a replicated distributed cache provides you greater resilience and non-stop operations, with the tradeoff being (and as memcached correctly states) that replication halves your effective cache size. Unfortunately Extstore doesn’t support warm restarts and thus the failure or maintenance of a single node is prone to elevating your cache miss ratios. Whether this is acceptable or not depends on your application semantics: If a cache miss corresponds to a round-trip to the database, then the end-to-end latency will be momentarily higher.
\ With regards to consistent hashing, memcached clients are responsible for distributing keys across your distributed servers. This may introduce some hiccups, as different client configurations will cause keys to be assigned differently, and some implementations may not be compatible with each other. These details are outlined in Memcached’s ConfiguringClient wiki. ScyllaDB takes a different approach: consistent hashing is done at the server level and propagated to clients when the connection is first established. This ensures that all connected clients always observe the same topology as you scale.
So who won (or who lost)? Well… This does not have to be a competition, nor an exhaustive list outlining every single consideration for each solution. Both ScyllaDB and memcached use different approaches to efficiently utilize the underlying infrastructure. When configured correctly, both of them have the potential to provide great cost savings.
\ We were pleased to see ScyllaDB matching the numbers of the industry-recognized Memcached. Of course, we had no expectations of our database being “faster.” In fact, as we approach microsecond latencies at scale, the definition of faster becomes quite subjective. 🙂
\
2026-01-29 18:59:59
HERMES shows that real-time video AI fails not from lack of memory, but from storing everything equally. By hierarchically compressing older context while preserving recent detail, it enables faster, more accurate streaming video understanding.
2026-01-29 18:45:15
For most of the internet era, educational technology followed a familiar pattern: digitize the textbook, put worksheets on a screen, maybe add a video. The goal was efficiency. Faster distribution. Easier grading. More content, more quickly.
But that model is starting to feel dated.
Today’s learners don’t just want information delivered. They expect to interact with it. Remix it. Build on top of it. The question is no longer whether technology belongs in education; it’s whether our education systems are keeping up with how young people already learn.
That’s what makes platforms like Roblox interesting.
At first glance, Roblox looks like “just a game.” In reality, it’s a massive, user-generated ecosystem where millions of young people design environments, write scripts, test mechanics, and collaborate with others in real time. It’s less like a console and more like a public sandbox for experimentation.
\
To formalize that shift, Roblox recently launched the Roblox Learning Hub, a curated experience that surfaces educational worlds across subjects like coding, math, climate science, digital citizenship, and life skills. Since July, the hub has drawn nearly 50 million visitors, a signal that families are actively searching for learning that feels native to how kids already spend time online.
Inside the hub, players can:
What’s different here isn’t just the content, it’s the structure. These aren’t lectures disguised as games. Players don’t “complete a lesson.” They interact with the world.
\
That matters because learning sticks when it’s experiential.
The Entertainment Software Association’s 2025 research reflects this shift: 45% of players say they use games to “keep their minds sharp,” and half report that games have improved their education or career trajectory. On platforms like Roblox, that’s visible in real time—kids debugging scripts, balancing virtual economies, collaborating across time zones, and iterating on designs based on feedback.
Adam Seldow, Senior Director of Education Partnerships at Roblox, frames it simply:
Play is one of the most powerful forms of learning. When kids explore and create together in immersive worlds, they aren’t just playing, they’re building the critical thinking skills they need to thrive.
This reframing challenges how we talk about “screen time.” The traditional fear assumes passivity: a child consuming content. But creator-driven platforms invert that dynamic. The screen becomes a tool for construction, not just consumption.
In that sense, Roblox doesn’t replace school, it models a different layer of learning:
On International Day of Education, UNESCO’s theme focuses on “the power of youth in co-creating education.” That’s exactly what these environments enable. Kids aren’t waiting for the curriculum to arrive. They’re building it.
The future classroom won’t be bounded by walls. It will look more like a shared world, one that students help design.
\
:::tip This story was distributed as a release by Jon Stojan under HackerNoon’s Business Blogging Program.
:::
\
2026-01-29 18:01:12
Victoria, Seychelles, January 29, 2026
MEXC, the fastest-growing global cryptocurrency exchange, redefining a user-first approach to digital assets through true zero-fee trading, today reported significant growth in precious metals futures trading, with gold futures market share reaching 47% on January 25, 2026, and single-day trading volume hitting $555 million.
MEXC's GOLD Futures market share grew from 2.4% in early December 2025 to 47% by January 25, 2026—a 20-fold increase over two months. The platform surpassed competitors to capture the largest market share on January 23, maintaining this position through month-end. The growth accelerated notably after January 15, coinciding with gold prices reaching new highs.
\ In response to heightened market activity, MEXC launched a limited-time Zero-Fee strategy on GOLD Futures (XAUT, PAXG) in mid-January. The initiative contributed to a 635% month-over-month increase in average daily trading volume from December 2025 to January 2026. Peak volume of $555 million was recorded on January 25.
\
\ The Zero-Fee strategy synergizes with MEXC's high-performance ecosystem: up to 100x leverage on GOLD futures and deep order book liquidity. This combination addresses key trading barriers—transaction costs, capital efficiency, and order execution—particularly for high-frequency and institutional-scale traders.
MEXC's SILVER Futures SILVER(XAG)USDT tracked similar growth patterns. Trading volume increased nearly 20-fold between January 18 and January 24, reaching a peak of $147.8 million. The surge aligned with silver's price rally beginning January 16.
\ With precious metals volatility expected to persist amid ongoing macroeconomic uncertainty, MEXC's Zero-Fee infrastructure and liquidity capacity position the platform to sustain its market leadership. The exchange plans to maintain competitive fee structures while continuing to expand derivatives product offerings across asset classes.
\
Founded in 2018, MEXC is committed to being "Your Easiest Way to Crypto." Serving over 40 million users across 170+ countries and regions, MEXC is known for its broad selection of trending tokens, everyday airdrop opportunities, and low trading fees. Our user-friendly platform is designed to support both new traders and experienced investors, offering secure and efficient access to digital assets. MEXC prioritizes simplicity and innovation, making crypto trading more accessible and rewarding.
\ MEXC Official Website | X | Telegram | How to Sign Up on MEXC
For media inquiries, please contact the MEXC PR Team: [email protected]
\
2026-01-29 18:00:40
Victoria, Seychelles, January 29, 2026
MEXC, the fastest-growing global cryptocurrency exchange, redefining a user-first approach to digital assets through true Zero-Fee trading, today released its 2025 Zero-Fee Strategy Annual Report. The ongoing commitment not only saved users a total of 1.1 billion USDT in fees but also bolsters both mainstream growth and emerging asset visibility, driving balanced development across the entire crypto landscape.
\ The platform's removal of fees across 3,026 spot trading pairs and 203 futures pairs resulted in significant savings for its users. Data shows 3.44 million users saved an average of $320 each, with the top single-user saving reaching $9 million. The move represented a significant shift in standard exchange fee models.
\ "We proved that Zero-Fee trading isn't a promotional tactic—it's a liquidity engine," the report states. The strategy delivered measurable competitive advantages, with MEXC capturing 72% market share in PUMPUSDT and 59% in LINKUSDT.
The "dual-market" approach demonstrated strategic precision: futures volume was anchored by mainstream assets (BTC& ETH made up 70% of the top 10), while emerging narratives surged. SUIUSDT ranked fourth, and USDC pairs exploded (BNBUSDC up 110x, SUIUSDC up 83x).
\ Zero-Fee proved particularly transformative for emerging assets. MNTUSDT gained 53% points in market share, while PUMP and LINK increased 42% and 34% respectively. The platform successfully bootstrapped new tokens while unlocking renewed trading potential in established assets across Layer 1s, DeFi, and oracle sectors.
\ In spot markets, MEXC established a commanding presence in the year's defining narrative: tokenized real-world assets (RWA). The exchange captured dominant market shares in leading tokenized equities—73% of McDonald's trading, 70% of Amazon, and 61% of Meta—while also securing 61% of Robinhood and 55% of Coinbase volume. This performance reinforced the platform's strategic "Widest Selection" positioning within the RWA landscape.
\ Since December 22, 2025, MEXC expanded Zero-Fee coverage to all spot trading pairs, removing the final barriers to entry for retail and institutional traders alike.
The report illustrates how MEXC's "MEXCmize, Zero-Fee, Infinite Opportunities" flywheel has transitioned from concept to a demonstrable market advantage. This was achieved by stripping away transaction costs to facilitate high-frequency strategies and providing consistent liquidity across the asset spectrum, thereby establishing a resilient competitive position.
We're not just building the lowest-cost exchange," the report concludes. "We're building the premier crypto gateway defined by lowest costs and widest selection—empowering global users to capture market opportunities and maximize asset value.
Access the full report here.
Founded in 2018, MEXC is committed to being "Your Easiest Way to Crypto." Serving over 40 million users across 170+ countries, MEXC is known for its broad selection of trending tokens, everyday airdrop opportunities, and low trading fees. Our user-friendly platform is designed to support both new traders and experienced investors, offering secure and efficient access to digital assets. MEXC prioritizes simplicity and innovation, making crypto trading more accessible and rewarding.
\ MEXC Official Website｜ X ｜ Telegram ｜How to Sign Up on MEXC
For media inquiries, please contact MEXC PR team: [email protected]
2026-01-29 18:00:18
Byline: Keith Belanger
AI projects have a way of surfacing data problems that data teams used to be able to work around. That’s because analytical data allowed for a wide margin of error, and AI simply doesn't. AI models don’t tolerate ambiguity, and decisions made at machine speed magnify every flaw hiding upstream. What once failed quietly now fails loudly, and often publicly.
AI failures are often dismissed as experimental growing pains. In reality, they’re revealing the weakness of existing operations. The uncomfortable truth is that most data organizations are not operationally prepared for AI, no matter how modern their platforms are or how sophisticated their models appear.
You see it when the first model retraining fails because a pipeline changed, when no one can explain why yesterday’s data looks different from today’s, or when “just rerun it” becomes the default response to production issues.
Gartner put it bluntly: “Above all, if the data has issues, then the data is not ready for AI.”
For years, most organizations lived with a fragile compromise. If pipelines broke occasionally, they could get fixed in time to meet deadlines. “Good enough” data quality was good enough. Governance existed somewhere in a shared drive. And when something broke, someone noticed and fixed it.
That model relied on people, not systems, to absorb complexity. Data teams compensated with heroics: Manual checks, late nights, and institutional memory passed informally from person to person.
The analytical data-era approach collapses when delivery shifts from weekly releases to multiple deployments per day.
Models consume data continuously, assume consistency, and amplify even small deviations. There’s no pause button to do manual checks or to confer about tribal knowledge.
Organizations can no longer declare readiness based on confidence or tooling. They need to start demonstrating it with continuous validation, lineage, scoring, rules, and enforcement in production.
Because “AI-ready” isn’t just a feeling. It’s a measurable state. AI-ready data is:
This evolution of data quality takes more than good intentions or best-practice documents. It requires systems designed to enforce reliability by default that can deliver continuous evidence of data trustworthiness.
Most enterprises already have powerful data platforms. What they lack is a way to operationalize those platforms with consistency at AI speed.
Manual processes don’t scale because humans only have so much attention to give.
AI workloads demand repeatability and the confidence that data will behave the same way today as it did yesterday—and that when it doesn’t, it gets flagged and fixed immediately.
Software engineering faced this problem years ago. As systems grew more complex and release cycles accelerated, manual processes and human vigilance stopped scaling. DevOps changed the game by operationalizing automation, testing, observability, and repeatable delivery.
Data is now at the same inflection point. The volume, velocity, and blast radius of failure have caught up to the operating model. DataOps offers data teams the same operational rigor that helped catapult software teams into the 21st century.
The organizations that succeed with AI will be the ones that treat data trust as an operational discipline.
That means that data pipelines need to be observed continuously, governed automatically, and proven in production with AI-ready data products.
The alternative is already playing out. Models stall in production, confidence in outputs erodes, and teams stop trusting the systems they built. When that happens, decision-makers quietly stop trusting AI altogether.
Meet the AI moment by embracing DataOps discipline and operationalizing your data with systems designed to deliver trust at AI speed.
\
:::tip This story was published under HackerNoon’s Business Blogging Program.
:::
\
