Building on Open Ground: Ilia Kors on Why Aqtra Chose MariaDB as the Native Foundation of Its Enterprise Platform
Q1. Aqtra is building a Development Infrastructure Layer that enables organisations, cloud providers, and service partners to create and operate business applications, ERP solutions, portals, and automation services on a common foundation. That is a significant architectural ambition — essentially becoming the infrastructure layer that others build on, rather than a point application. Can you explain what the Development Infrastructure Layer concept actually means in practice, what problem it solves that existing enterprise platforms do not, and why you believe the market needs a new common foundation rather than continued specialization at the application layer?
The concept of the Development Infrastructure Layer (DIL) was born not as a product idea, but as the result of more than ten years of consulting practice. During that time, we implemented many enterprise solutions in HR, Finance, Logistics, and other business domains based on Microsoft technologies and other platforms. Every single time we faced exactly the same situation. Regardless of the business problem, we had to build the same technical infrastructure again and again. Before writing the first line of business logic, we had to design the architecture, configure databases, infrastructure, CI/CD, security, deployment processes, monitoring, version management, and much more. None of this created value for the customer, yet it significantly increased the development timeline, project cost, and long-term maintenance.
In 2020, while working on another large project for KFC, we asked ourselves a simple question: Why do we rebuild the same engineering foundation every single time? That was the moment when the idea emerged to create a universal layer that would take over all the technical complexity, allowing developers to focus only on describing business logic. That is how the Development Infrastructure Layer was born.
Instead of manually assembling the application architecture every time, the developer describes the business domain model, while the platform itself is responsible for validation, publishing, version management, infrastructure, and runtime. In essence, we move complexity from every individual project into the platform itself.
There was also a personal reason. At that time, my twenty-year-old son decided to study sociology, which, as an engineer, I took rather painfully. I really wanted to show him that building software should not begin with learning dozens of technologies and infrastructure tools. That was when I seriously started asking myself: Is it possible to build a system where complex enterprise applications could be created by a junior developer without simultaneously becoming a software architect, a DevOps engineer, and a database expert?
Today, this question has become even more relevant. The industry is experiencing a shortage of strong engineers, especially enterprise architects and data specialists. At the same time, the rapid growth of AI and what is now called vibe coding accelerates code generation, but does very little to solve architecture, change management, data model quality, or long-term maintainability. If anything, the volume of code is growing faster than its quality.
That is why I believe the next stage of our industry is not about generating even more code. It is about building platforms that allow systems to be created on top of validated models, trusted metadata, and built-in architectural principles.
If I had to describe the idea behind DIL in one sentence, it would be this:
We do not eliminate the complexity of software development—we move it from every individual project into the infrastructure layer, where it is solved once and then reused over and over again.
Q2. You started with PostgreSQL and made the deliberate decision to move to MariaDB as the native database foundation of Aqtra’s next-generation architecture. That is not a trivial switch — it involves significant engineering investment and a long-term platform bet.
Most enterprise platform teams, once they have built on PostgreSQL, do not move.
What specifically made that migration worth the cost, and what did you discover about the technical and architectural differences between PostgreSQL and MariaDB in the context of building a platform that others will build on — not just use — that drove the decision?
First of all, I would like to go back to the previous question. Since we are building a Development Infrastructure Layer, for us the database is not just a place to store business data. It is part of the infrastructure layer of the platform itself. That is why our move to MariaDB should not be viewed as a traditional migration from one database to another. Rather, it is the replacement of one metadata storage and processing engine with another.
Developers building solutions on top of DIL do not interact with the database directly at all. They work with the business domain model, while the platform itself is responsible for implementing, publishing, and executing that model. At the same time, it is extremely important for us to give our customers freedom of choice. Enterprise customers operate in very different infrastructure environments and have their own standards and technology stack requirements. Our goal is to make sure that the choice of a particular database never limits the use of the platform.
MariaDB became a strategic choice for us not only because of its current technical capabilities. Over the past several years, the MariaDB team has done an outstanding job in terms of performance, scalability, and the overall evolution of the platform. We are also watching very closely how MariaDB is evolving in the areas of artificial intelligence technologies and modern data processing.
This is particularly important for Aqtra because we see DIL not only as a platform for developing enterprise applications, but also as the foundation for the next generation of AI-native software development. We are building mechanisms for the deep integration of artificial intelligence directly into the process of designing and building applications.
In that context, MariaDB is not simply a database management system for us—it is one of the key building blocks of the platform’s long-term architecture.
Q3. Aqtra claims to increase development speed by 5x, decrease technical errors by 100x, and reduce the number of developers required by 3x — significant claims for any low-code platform. The low-code market is crowded with similar performance promises from well-funded competitors including Appian, OutSystems, and Bubble. What is the specific architectural reason — particularly at the database and infrastructure layer — that you believe Aqtra can deliver on those numbers in enterprise environments where those competitors have struggled to achieve consistent results at scale?
You are absolutely right—the market today is crowded with low-code platforms, and almost every one of them promises dramatically faster development. But if you look closely at what they actually offer, the difference becomes quite obvious.
Most of these platforms solve only part of the problem: they help developers build user interfaces faster, automate business processes, or assemble applications. At the same time, architecture, infrastructure, deployment, scalability, security, CI/CD, version management, and operations remain the customer’s responsibility. That is why the real total cost of ownership of these solutions is often much higher than it appears during the evaluation stage.
From the very beginning, we built DIL differently. Our goal was not simply to accelerate coding. Our goal was to cover the entire software development lifecycle—from the initial idea and design through deployment, scaling, and long-term maintenance. Developers should not have to think about how to build the architecture, organize the infrastructure, or provide high availability. All of these mechanisms are already built into the platform.
Architecturally, DIL is a microservices platform with both horizontal and vertical scaling. It was designed from the beginning as the core foundation for enterprise systems and SaaS solutions capable of serving hundreds of thousands—or even millions—of users. In other words, customers do not need to build a platform first and then develop an application. The platform already exists.
This is where the real speed advantage comes from. Developers do not start every new project by building engineering infrastructure. They start directly with business logic because most of the difficult architectural decisions have already been made, implemented, and validated inside DIL.
There is another reason why we are confident in the numbers we quote. It is directly related to how software development works inside the platform.
Like many modern solutions, we use a hybrid approach that combines declarative development with traditional programming. However, if you take a closer look at the functional programming model inside DataFlow DIL, you will find that there are very few, if any, comparable approaches. Developers are not limited to a predefined set of components or scenarios. They can create their own objects, design arbitrary data models, and implement virtually any business logic. It was extremely important for us to build not another process automation tool, but a universal software development environment.
People often ask me how Aqtra is better than a CRM, ERP, or WMS. In reality, I think that is the wrong comparison. We do not compete with those systems as finished products. Using DIL, you can build a CRM, an ERP, a WMS, or virtually any other enterprise system. The opposite is simply not possible. A specialized enterprise application cannot become a universal software development platform.
That is exactly why we never tried to reproduce existing products. Our goal was completely different—to solve the fundamental technical and methodological challenges of developing complex enterprise systems by bringing architecture, infrastructure, and development tools together in a single platform while preserving maximum flexibility.
This architecture is already delivering practical results. Our MSP partners have real projects where migrating large enterprise solutions to DIL takes 10 to 12 months, while similar systems previously required years to build. The reason is not that developers suddenly write code faster. It is simply that they no longer have to rebuild the platform for every new project.
There is another aspect that was very important to me personally—the total cost of ownership. I wanted even a relatively small company to be able to access enterprise-grade infrastructure for a relatively small annual cost. If an organization wants to build a specialized CRM for logistics or its own ERP system, it should not have to invest hundreds of thousands of dollars just to build the technological foundation. It should be able to focus on its own business domain while trusting the platform to handle the engineering complexity.
So when we talk about accelerating software development, we are not saying that developers suddenly write code faster. What we have done is eliminate an enormous amount of repetitive engineering work that traditionally has to be repeated in almost every project.
For me, speed has always been one of the highest engineering values. But speed by itself means nothing if it comes at the expense of quality or results in a higher total cost of ownership. Engineering has always been about balancing speed, quality, and cost. DIL is our attempt to move that balance into the platform itself by embedding engineering best practices directly into its foundation. That allows developers to focus on solving business problems without sacrificing quality, scalability, or reliability.
Q4. By joining MariaDB Foundation as a Gold Sponsor, you are not only adopting MariaDB as a strategic technology component but also supporting the ecosystem that helps organisations build and operate business-critical applications on open infrastructure.
That is a meaningful financial commitment for a young company. What is the strategic reasoning behind investing in the MariaDB Foundation at the Gold level rather than simply using MariaDB as a dependency — and what do you see as the relationship between Aqtra’s commercial success and the health of the open source ecosystem on which your platform depends?
That is a very good question.
For us, becoming part of the MariaDB Foundation is much more than simply using MariaDB as a technology component. We see ourselves as part of the ecosystem, and we believe that if you build your product on open technologies, you should not only use them but also contribute to their development.
There is also a practical side to this decision. It is extremely important for us to be close to the professional community—software architects, platform developers, database engineers, and all those people who, in the future, will build solutions on top of DIL. I deliberately say users rather than customers, because they are the real driving force behind the evolution of the technology.
Until now, we have been almost entirely focused on building the platform itself. As a result, we have devoted much less attention to building a professional community around it. Joining the MariaDB Foundation gives us the opportunity to become part of an already strong engineering ecosystem, exchange knowledge, and grow together with people who share similar technical values.
I would also like to recognize Anna Widenius, CEO of the MariaDB Foundation. She has created a very open and constructive environment within the community. Thanks to her leadership, the Foundation is much more than an organization that supports open source—it is a place where companies can collaborate naturally, share experience, and develop technologies together.
In the long term, I am convinced that the commercial success of companies like Aqtra is directly connected to the health of the open-source ecosystem. When the ecosystem grows stronger, everyone benefits: developers gain better technologies, companies gain a more reliable foundation for their products, and customers gain greater freedom of choice.
That is why, for us, supporting the MariaDB Foundation is not a marketing initiative. It is a natural part of our long-term strategy.
Q5. Aqtra is founded in Tbilisi, Georgia — not Silicon Valley, not London, not Berlin. Building an enterprise platform company competing with well-funded American and European incumbents from a geography that most enterprise buyers would not immediately associate with tier-one infrastructure software is a genuine challenge. How does being based in Georgia shape your approach to building, selling, and partnering — and what advantages, if any, does that location give you that are less visible from the outside?
To be honest, today Aqtra is already a highly distributed international company. Our headquarters are in the United States, our primary R&D organization is based in Israel, and Georgia became a great place for us to start. It was a very pragmatic decision. Georgia offered a strong engineering environment, and its favorable conditions for technology companies allowed us to focus our resources on building the product rather than on administrative overhead. For an early-stage startup, that makes a huge difference.
At the same time, our team has never been limited to a single country. From the very beginning, we brought together engineers from different countries with different professional backgrounds. What has always mattered to us was not where a person is located, but their engineering culture, professionalism, and passion for building complex technology.
I am convinced that if we had started building DIL in Silicon Valley, the cost of development would have been dramatically higher. It is quite possible that we simply would not have been able to build such an ambitious architecture. Instead, we built the platform with a relatively small but exceptionally strong engineering team, focusing on engineering excellence rather than raising hundreds of millions of dollars in investment.
In my opinion, that became one of our biggest advantages. Limited resources force you to make better architectural decisions, think carefully about long-term efficiency, and build real technology instead of solving problems simply by scaling the size of the team.
Ultimately, our greatest advantage has never been geography. It has always been engineering.
Q6. You are a co-founder and CTO building what you describe as a Development Infrastructure Layer — infrastructure that enterprises, cloud providers, and service partners will depend on for their most critical business applications. That is a very high bar for reliability, longevity, and trust. What is the hardest decision you have made so far in building Aqtra — the one where the technical path and the business path pointed in different directions, where you had to choose between what was architecturally right and what would move the company forward fastest — and how did you resolve it?
That is probably the most interesting question.
I would say that the hardest decision was not to compromise on the architecture, even when it seemed that the project was doomed to fail.
During the first year of developing DIL, we threw away everything we had built—twice. We honestly admitted to ourselves that the architecture simply wasn’t working the way it should, and we started almost from scratch each time. At one point, I began to think that the idea itself was impossible to implement. We were financing the development with our own money, and more than once I seriously thought about shutting the project down and going back to consulting. It would have been much easier, and probably much more rational.
That was exactly when our first potential customer appeared. He looked at a very early version of the platform and said something I still remember today:
“Guys, the idea is interesting, but it’s impossible to use.”
And then, unexpectedly, he added:
“But I’m willing to give you a chance.”
For me, that was already the third chance.
At that moment I realized one thing: if we started looking for a compromise between what the market expected and the platform I wanted to build, we would end up creating just another ordinary product. So I made a rather risky decision and promised that within three months we would demonstrate a real prototype built entirely on the DIL platform itself.
To be honest, it was a complete adventure. For the next three months, my chief architect and I lived and breathed that challenge. Every single day we came up with solutions to problems that had seemed impossible only the day before. Many of the key ideas were born while we were building the prototype itself.
And then something happened that even we hadn’t fully expected—the platform actually worked. That was the moment when we realized that the concept was truly viable.
Looking back today, I understand that the hardest decision was not a technical one. The hardest decision was refusing to take the easy path. We could have released a much more conventional product, added individual features, and followed the same direction as everyone else. But then we would never have built the Development Infrastructure Layer the way we envision it today.
Sometimes the right engineering decision looks like the riskiest business decision.
In our case, that risk became the turning point for the entire company.
Qx. Anything else you wish to add?
For the last twenty years, our industry has focused on making developers more productive. AI will accelerate that trend even further. But productivity is no longer the fundamental problem. The real challenge is preserving architectural quality as software becomes easier to generate. I believe the next generation of development platforms will be built around validated metadata, engineering governance, and AI working within strong architectural boundaries rather than replacing them. That is the direction we are pursuing with DIL.
…………………………………………………….
Ilia Kors is the Co-Founder and CTO of Aqtra and the architect of its Development Infrastructure Layer (DIL). With more than a decade of experience delivering enterprise transformation projects, he specializes in enterprise architecture, distributed systems, metadata-driven development, and database technologies. His current focus is AI-native software engineering and the future of enterprise application development.