The alpha and omega of our times is performance and speed. And in e-commerce this is especially true. As soon as a customer waits a little longer for a response and rendering of the products in the e-shop, they lose patience and go elsewhere. In an extremely competitive environment, speed is a key parameter for an e-commerce business to succeed. evitaDB is a highly specialized database targeted for e-commerce needs, where currently available solutions are often not satisfactory. Try a barrier-free solution for your solution, which can take your e-shop several levels further in speed and data handling at minimal cost and regardless of your platform vendor. And gain a valuable advantage over your competitors.
100×
faster than*
PostgreSQL
10×
faster than*
Elasticsearch
*) Results from development and testing so far. Are you interested in how we test and what we test on?
Be among the first to hear about the launch of evitaDB!
Want to be among the first to test the database on your data? Leave us your contact details and we will include you in an exclusive round of testing and feedback.
Extreme read speed and data filtering
The database was designed to answer complex queries that are common in the implementation of e-commerce catalogues with low latency in mind. All indexes are strictly held in RAM in immutable data structures allowing lock-free parallel reads. We achieve (and test for) millisecond latencies for filtering and sorting records with cardinality in the units of millions of entries.
The basic requirements for an e-commerce website are addressed directly by the database
Every e-commerce catalogue author has to deal with a hierarchical category structure, data localization, facet filtering and prediction, and often complex B2B pricing that complicates real-time filtering and sorting by price in the desired currency and VAT rate. The database can also cope with different pricing of product variants or dynamic pricing of bundles consisting of multiple different separately sold products.
Smart cache
Thanks to the intelligent cache built directly into the database machine, there is no need to create additional application caches and thus complicate the infrastructure of the final solution. Due to versioning and the immutable nature of internal data structures, it is not possible for the database to return stale data from the cache that does not match the last applied data changes. The cache can be configured to be persistent and therefore there is no need to warm up the cache after a database restart.
Immediately consumable GraphQL/REST/gRPC API
You can design the database schema in advance and strictly validate its consistency, or you can take an agile approach to design and let the schema adapt to your data. Based on the database schema the GraphQL schema or REST OpenAPI schema are immediatelly exposed allowing frontend developers (which are often different people than those who deal with the backend and data structure) to navigate the database structure and access the data easily. Through relations to other entities, it is possible to get a complete entity graph required for rendering the entire page on the frontend.
Support for ACID transactions except for initial data fill
The database operates in two modes - the initial phase is optimized for write speed and does not allow transactions. The goal is to allow the search index to be populated as quickly as possible from an empty state based on the state of the primary data store. Once switched to execution mode, all subsequent incremental database updates are then in ACID-compliant snapshot isolation mode.
Trivial deployment and operation
The database can be run as part of a Java application (embedded) or as a separate process. The data files are part of a single folder on disk and transferring the e-commerce catalog database between different environments is a matter of simply copying the data without the need to stop the process. Working with the database must be an enjoyable experience for every member of the development team.