At the WeAreDevelopers Conference in Berlin, I met with Zohar Elkayam (Principal Solutions Architect, Aerospike) to talk about one of the most common mistakes engineering teams still make: choosing a database because it’s familiar, instead of choosing it for the actual problem they need to solve.
It sounds like a small decision at first, but as Zohar explains, it can become a costly one later when teams have to deal with scale, reliability, latency, and re-architecture.
We also discussed what changes when you build for real-time AI workloads, and why predictable performance matters far more than averages when your users expect speed every time.
When teams pick a database today, what do they most often get wrong? #
Zohar: Most people start by thinking about the databases they already know and have used in previous roles, rather than what they actually need for the specific use case in front of them.
As a result, we often see customers choose
something familiar instead of evaluating variables such as latency, speed, scale, reliability, and consistency, and selecting the right solution for their particular problem.
That becomes a major issue when they later have to revisit their decision and re-architect or refactor the solution. It can be time-consuming, costly, and extremely difficult.
As AI apps get more real-time and data-heavy, how should developers and CTOs rethink database architecture? #
Zohar: Traditional web applications focused on human interaction and often relied on caches and in-memory data. When we talk about real-time systems and AI, however, we are talking about high-throughput, low-latency workloads that consume large amounts of data and need it immediately.
Because of this, teams sometimes use solutions that no longer fit their needs. They require systems that are reliable, predictable, fast, and scalable, which is something we see all the time. Aerospike was built for exactly that use case: real-time workloads, low latency, predictability, and high throughput.
From my perspective, when CTOs evaluate this kind of solution, they need to think about the future. They should consider what they need today, but also where the product and its infrastructure will need to be at the next stage. That is especially important for AI applications and real-time applications in general.
Many teams are adding vector search, graph databases, and real-time pipelines to their stack. When is that the right choice? #
Zohar: When many customers think about AI, their first reaction is: ‘This is what my competitor is doing, so I need to do it too. Sometimes, when we examine the use case, we find it provides no real value. Teams choose to do it simply because everyone else is doing it.
These solutions shine when they provide a competitive advantage, and AI can be integrated into the system in a way that creates long-term value. If you integrate a graph database or vector-search solution simply because someone else is doing it, you are going to have a very difficult time.
From that point onward, everything you do can become a technological hurdle, which is exactly where you do not want to be. You need to focus on what will create the most value. If AI is one of those things, go for it. If it is not, you should probably consider other solutions.
What should engineering teams measure if they really want to understand database performance at scale? #
Zohar: When it comes to database performance, predictability is the number-one factor. It should be the industry standard for anything involving low latency and high throughput.
Focusing on the average can put you in a dangerous position. Think of a swimming pool with an average depth of 30 centimeters: you can still drown in the deep end.
You need to think differently about performance. Focus on predictability and metrics such as P99 or even P99.9. Measure them at the application level, the database level, and across the overall user experience, because that is what will make your life easier later.
If you measure only the average, 50 percent of your users will experience latency worse than that figure. If you measure P99, the 99th percentile, only 1 percent of users will experience worse latency. A long performance tail can be highly problematic for some use cases. Our main focus is providing long-term predictability at the high end, including P99.9 and beyond.
That predictability cannot depend on memory or caches. It needs to hold when reading from disk, NVMe, or other storage, without relying on prior activity, cache hits, or warming data into memory.
What do teams give up or gain when they move fast with managed tools versus building something custom? #
Zohar: If you are a startup building a proof of concept or just getting started, using off-the-shelf tools is perfectly fine. Over the long term, however, those tools can impose strict limitations. They can be expensive, slow, or unreliable, and they may change without your consent or even your knowledge. They can help you build quickly and get to market fast.
But once you reach a more established stage, you need to find a different way to handle things.
That may mean building your own solutions, adopting a data platform, and unifying your stack. You look for ways to differentiate your product from competitors and make it more scalable, faster, and more valuable.
It all comes down to value. If your solution provides something no one else can, and that differentiation comes from a different architecture or infrastructure, then it makes sense.
Ultimately, it is not one approach or the other. You need to combine them: use common tools to solve common problems, while applying the right technologies to the uncommon, differentiating parts of each use case.
What database and infrastructure skills should software engineers focus on to stay relevant as AI changes development? #
Zohar: I think AI is a major accelerator for developers, SREs, and DevOps teams, dramatically speeding up their work. Even so, people need to stay mindful and continue developing deep expertise in their field when working with AI.
It is like generating an image with AI. You enter a prompt and get a result, but it may not be exactly what you wanted or imagined. To the human eye, the problem is often immediately obvious: the image may show six fingers, strange features, or something else you did not expect. The same applies when you are writing code or analyzing logs.
You need enough expertise to evaluate the response critically. You have to ask why: Why did the AI give me that answer? Where did it come from? What did I learn, and how can I improve my solution?
Instead of using AI only to generate and build things, use it to learn. You can still use it to generate code or solve problems, but you need to be able to read the output, understand it, and guide the AI so that it produces results that make sense for you.
When you build an agentic system, use multiple agents, and pass outputs from one to another, you can sometimes lose that visibility. But if you preserve it over the long term, CTOs, developers, newcomers, and junior engineers can go very far, provided they understand what is actually happening.
From my perspective, AI is where the industry is heading. I use it every day and across many parts of my work, but I always remain critical. I plan before I act. It is not about wasting tokens; it is about creating value through my work.