FoundationDB NoSQL Database Supports ACID Transactions

FoundationDB database platform combines NoSQL scalability with ACID transactions across all data within the database. FoundationDB team announced last month the availability of its new NoSQL database platform.

NoSQL databases usually don't support ACID transactions across multiple data elements for scalability reasons but weak transaction guarantees can result in inconsistent data. Built on a distributed shared-nothing architecture, FoundationDB supports a diverse set of applications and data models using a concept called "layers" which map different data models to the ordered keys and values in the database. Applications built on these layers inherit the performance, data consistency and operational features of the core database.

InfoQ spoke with Dave Rosenthal and Nick Lavezzo from FoundationDB team about the new release, product features and how it compares with relational database models as well as with other NoSQL database technologies.

Nick talked about the current status of the database product. The new release is in Beta right now but it’s production ready. The product has been tested internally for the past few years, and it has been in alpha testing program for more than a year.

Responding to a question on how FoundationDB compares with relational databases (RDBMS) and with other NoSQL databases, Dave said FoundationDB combines the simple API and distributed design of NoSQL systems with the ACID transactions of RDBMSs.

InfoQ: Can you elaborate on how the database supports the CAP theorem and what it means for those three concerns: Consistency, Availability, and Partition-Tolerance?

Dave: The CAP theorem states that when a partition occurs in a distributed system you can choose either consistency or availability. As any transactional database must, FoundationDB chooses consistency. A system with both these capabilities is difficult to build, but not impossible.

InfoQ: What are the limitations or constraints of using FoundationDB database?

Dave: We carefully document both capabilities that FoundationDB is not designed to have, as well as known limitations in the current version of FoundationDB. We think it is very important to understand the limitations of any tool as important as a database.

InfoQ: What is the future of NoSQL databases in general and what do you see as the role of Relational databases in the overall data management landscape?

Dave: Of course, relational databases are not going anywhere soon, but other database technologies are narrowing the scope of problems for which RDBMSs are the best choice. The analytics market was the first place that traditional RDBMSs got displaced by the likes of Teradata, and now Hadoop is rapidly becoming the new standard for batch processing. NoSQL databases are now proving themselves as valid alternatives for scalable, operational systems.

FoundationDB will be available as both a free community edition and a licensed version with support and larger cluster capability. The community edition will include the full capabilities of FoundationDB and will allow production deployment. Developers can now sign up for the beta to evaluate FoundationDB and contribute layers via the Beta community site.

The website also includes several white-papers with information about the design and implementation of FoundationDB.

Aerospike is a distributed NoSQL database and key-value store architected for the performance needs of today’s web-scale applications; providing robustness and strong consistency with no downtime. Learn more.

Documentation in FoundationDB for storage engine, state that "commits transactions to disk with the number of copies indicated by the redundancy mode before reporting them committed. This procedure guarantees the durability needed for full ACID compliance. At the point of the commit, FoundationDB *may have only logged* the transaction, deferring the work of updating the disk representation. This deferral has significant advantages for latency and burst performance. Due to this deferral, it is possible for disk space usage to continue increasing after the last commit.” What does this mean? does it mean that all replicas are written before returning from commit, but still haven't fsync() to disk/san, but operation is differed? if so how FoundationDB handles site/data center failures?

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.