If database technologies offered performance, flexibility and security, most professionals would be happy to get two of the three, and they might have to expect to accept some compromises, too. Systems optimised for speed demand manual tuning, while flexible platforms can impose costs when early designs become constraints. Security is, sadly, sometimes, a bolt-on, with DBAs relying on internal teams\u2019 skills and knowledge not to introduce breaking changes.<\/p>\n
RavenDB, however, exists because its founder saw the cumulative costs of those common trade-offs, and the inherent problems stemming from them. They wanted a database system that didn\u2019t force developers and administrators to choose.<\/p>\n
Abstracting away complexity<\/p>\n
Oren Eini, RavenDB\u2019s founder and CTO was working as a freelance database performance consultant nearly two decades ago. In an exclusive interview he recounted how he encountered many capable teams \u201cdigging themselves into a hole\u201d as the systems in their care grew in complexity. Problems he was presented with didn\u2019t stem from developers not possessing the required skills, but rather from system architecture. Databases tend to guide their developers towards fragile designs and punish developers for following those paths, he says. RavenDB was a project that began as a way to reduce friction when the unstoppable force of what\u2019s required meets the mountain of database schema.<\/p>\n
The platform\u2019s emphasis is on performance and adaptability without (ironically) at some stage requiring the services of people like Oren. Armed with a bag full of experience and knowledge, he formed RavenDB, which has now been shipping for more than fifteen years \u2013 well before the current interest in AI-assisted development.<\/p>\n
The bottom line is that over time, the RavenDB database adapts to what the organisation cares about, rather than what it guessed it might care about when the database was first spun up. \u201cWhen I talk to business people,\u201d Eini says, \u201cI tell them I take care of data ownership complexity.\u201d<\/p>\n
For example, instead of expecting developers or DBAs to anticipate every possible query pattern, RavenDB observes queries as they are executed. If it detects that a query would benefit from an index, it creates one in the background, with minimal overhead on extant processing. This contrasts with most relational databases, where schema and indexing strategies are set by the initial developers, so are difficult to alter later, regardless of how an organisation may have changed.<\/p>\n
Oren draws the comparison with pouring a building\u2019s foundations before deciding where the doors and support columns might go. It\u2019s an approach that can work, but when the business changes direction over the years, the cost of regretting those early decisions can be alarming.<\/p>\n
Oren Eini (source: RavenDB)<\/p>\n
Speaking ahead of the company\u2019s appearance at the upcoming TechEx Global event in London this year (February 4 & 5, Olympia), he cited an example of a European client that struggled to expand into US markets because its database assumed a simple VAT rate that it had consigned to a single field, a schema not suitable for the complexities of state and federal sales taxes. From seemingly simple decisions made in the past (and perhaps not given much thought \u2013 European VAT is fairly standard), the client was storing financial pain and technical debt for the next generation.<\/p>\n
Much of RavenDB\u2019s attractiveness is manifest in practical details and small tweaks that make databases more performant and easier to address. Pagination, for example, requires two database calls in most systems (one to fetch a page of results, another to count matching records). RavenDB returns both in a single query. Individually, such optimisations may appear minor, but at scale they compound. Oren says. \u201cIf you smooth down the friction everywhere you go, you end up with a really good system where you don\u2019t have to deal with friction.\u201d<\/p>\n
Compounded removal of frictions improves performance and makes developers\u2019 jobs simpler. Related data is embedded or included without the penalties associated with table joins in relational databases, so complex queries are completed in a single round trip. Software engineers don\u2019t need to be database specialists. In their world, they just formulate SQL-like queries to RavenDB\u2019s APIs.<\/p>\n
Compared to other NoSQL databases, Raven DB provides full ACID transactions by default, and reduced operational complexity: many of its baked-in features (ETL pipelines, subscriptions, full-text search, counters, time series, etc.) reduce the need for external systems.<\/p>\n
In contrast with DBAs and software developers addressing a competing database system and its necessary adjuncts, both developers and admins spend less time sweating the detail with Raven DB. That\u2019s good news, not least for those that hold an organisation\u2019s purse strings.<\/p>\n
Scaling to fit the purpose<\/p>\n
RavenDB is also built to scale, as painlessly as it handles complex queries. It can create multi-node clusters if wanted so supports huge numbers of concurrent users. Such clusters are created by RavenDB without time-consuming manual configuration. \u201cWith RavenDB, this is normal cost of business,\u201d he says.<\/p>\n
In February this year, RavenDB Cloud announced version 7.2, and this being 2026, mention needs to be made of AI. Raven DB\u2019s AI Assistant is, \u201cin effect, [\u2026] a virtual DBA that comes inside of your database,\u201d he says. The key word is inside. It\u2019s designed for developers and administrators, not end users, answering their questions about indexing, storage usage or system behaviour.<\/p>\n
AI as a professional tool<\/p>\n
He\u2019s sceptical about giving AIs unconfined access to any data store. Allowing an AI to act as a generic gatekeeper to sensitive information creates unavoidable security risks, because such systems are difficult to constrain reliably.<\/p>\n
For the DBA and software developer, it\u2019s another story \u2013 AI is a useful tool that operates as a helping hand, configuring and addressing the data. RavenDB\u2019s AI assistant inherits the permissions of the user invoking it, having no privileged access of its own. \u201cAnything it knows about your RavenDB instance comes because, behind the scenes, it\u2019s accessing your system with your permissions,\u201d he says.<\/p>\n
The company\u2019s AI strategy is to provide developers and admins with opinionated features: generating queries, explaining indexes, helping with schema exploration, and answering operational questions, with calls bounded by operator validation and privileges.<\/p>\n
Teams developing applications with RavenDB get support for vector search, native embeddings, server-side indexing, and agnostic integration with external LLMs. This, Oren says, lets organisations deliver useful AI-driven features in their applications quickly, without exposing the business to risk and compliance issues.<\/p>\n
Security and risk<\/p>\n
Security and risk comprise one of those areas where RavenDB draws a clear line between it and its competitors. We touched on the recent MongoBleed vulnerability, which exposed data from unauthenticated MongoDB instances due to an interaction between compression and authentication code. Oren describes the issue as an architectural failure caused by mixing general-purpose and security-critical code paths. \u201cThe reason this is a vulnerability,\u201d he says, \u201cis specifically the fact that you\u2019re trying to mix concerns.\u201d<\/p>\n
RavenDB uses established cryptographic infrastructure to handle authentication before any database logic is invoked. And even if a flaw emanated from elsewhere, the attack surface would be significantly smaller because unauthenticated users never reach the general code paths: that architectural separation limits the blast radius.<\/p>\n
While the internals of RavenDB are highly technical and specialised, business decision-makers can easily appreciate that delays caused by schema changes, performance tuning, or infrastructure changes will have significant economic impact. But RavenDB\u2019s malleability and speed also remove what Oren describes as the \u201cno, you can\u2019t do that\u201d conversations.<\/p>\n
Organisations running RavenDB reduce their dependency on specialist expertise, plus they get the ability to respond to changing business needs much more quickly. \u201c[The database\u2019s] role is to bring actual business value,\u201d Eini says, arguing that infrastructure should, in operational contexts, fade into the background. As it stands, it often determines the scope of strategy discussions.<\/p>\n
Migration and getting started<\/p>\n
RavenDB uses a familiar SQL-like query language, and most teams will only need a day at most to get up to speed. Where friction does appear, Oren suggests, it is often due to assumptions carried over from other platforms around security and high availability. For RavenDB, these are built into the design so don\u2019t cause extra workload that needs to be factored in.<\/p>\n
Coming about as the result of the experience of operational pain by the company\u2019s founder himself, RavenDB\u2019s difference stems from accumulated design decisions: background indexing, query-aware optimisation, the separation of security and authentication issues, and latterly, the need for constraints on AI tooling. In everyday use, developers experience fewer sharp edges, and in the longer term, business leaders see a reduction in costs, especially around the times of change. The combination is compelling enough to displace entrenched platforms in many contexts.<\/p>\n
To learn more, you can speak to RavenDB representatives at TechEx Global, held at Olympia, London, February 4 and 5. If what you\u2019ve read here has awakened your interest, head over to the company\u2019s website.<\/p>\n
(Image source: \u201c#316 AVZ Database\u201d by Ralf Appelt is licensed under CC BY-NC-SA 2.0.)<\/p>\n
Want to learn more about AI and big data from industry leaders? Check out AI & Big Data Expo taking place in Amsterdam, California, and London. The comprehensive event is part of TechEx and co-located with other leading technology events. Click here for more information.<\/p>\n
AI News is powered by TechForge Media. Explore other upcoming enterprise technology events and webinars here.
\nThe post Lowering the barriers databases place in the way of strategy, with RavenDB appeared first on AI News.<\/p>\n","protected":false},"excerpt":{"rendered":"
If database technologies offered performance, flexibility and security, most professionals would be happy to get two of the three, and they might have to expect to accept some compromises, too. Systems optimised for speed demand manual tuning, while flexible platforms can impose costs when early designs become constraints. Security is, sadly, sometimes, a bolt-on, with [\u2026]<\/p>\n
The post Lowering the barriers databases place in the way of strategy, with RavenDB<\/a> appeared first on AI News<\/a>.<\/p>\n<\/div>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"site-container-style":"default","site-container-layout":"default","site-sidebar-layout":"default","disable-article-header":"default","disable-site-header":"default","disable-site-footer":"default","disable-content-area-spacing":"default","footnotes":""},"categories":[1,67,512,69,75,499],"tags":[3],"class_list":["post-843","post","type-post","status-publish","format-standard","hentry","category-ai-and-ml","category-ai-in-action","category-data-engineering-mlops","category-features","category-sponsored-content","category-techex-events","tag-ai"],"yoast_head":"\n