What happened to NEXTGRES?

I’ve received a few questions in regard to the state of my company, NEXTGRES, and why the site now only contains a terse reference to the Janus Database Compatibility System. While it’s not specifically related to Oracle Database internals, as it’s been discussed on my blog and Twitter for many years, here’s an update.

Misconceptions
Over the years, people seemed to think NEXTGRES was about migrating away from commercial databases, specifically SQL Server and Oracle Database; this was never the case. The premise behind NEXTGRES was, and always will be, to promote freedom of data. In fact, I spoke to just as many MySQL users who wanted to migrate their databases to Oracle Database as Oracle Database users wanting to migrate to Postgres. I understand where this misconception originated, however, and this is that story.

The History of NEXTGRES
When I first started NEXTGRES, the software was designed to be a database migration platform not tied to any single database vendor. Originally, the platform supported applications developed for Postgres, MySQL, SQL Server, DB2, and Oracle Database. Unlike other vendors offering a compatible database, the NEXTGRES platform did this in a unique way: by emulating the network protocol, the SQL dialect, the procedural language, and–most importantly–the behavior of a database engine. And, it did this in such a way that it was completely transparent to the application – the application didn’t even know it was running on a different database. As a result, in many cases, zero lines of code had to be changed – significantly reducing the overall cost and time involved in migrating.

Paired with a native in-database runtime, as the platform was originally written to use an ODBC connection to the backend database, it was able to emulate the above-mentioned systems on top of whatever database vendor the customer wanted to use – hence, freedom. Because of this, one could emulate MySQL on top of Oracle Database just as easily as MySQL on top of SQL Server – and vice versa. In terms of development resources, though, emulating behaviors outside the database is extremely difficult to accomplish in a performant way, and supporting this many database combinations was too much to handle. Consequently, I had to reduce the product to only emulating MySQL, SQL Server, and Oracle Database on top of Postgres.

By limiting the backend database support to only Postgres, which I have a significant amount of development knowledge in, I could focus on adding everything needed to support better and faster emulation. While this created a much better product, in terms of customers, something I’d faced back in 2005-2008 kept creeping in.

When I worked at EnterpriseDB, our most difficult selling point was not the feature set we supported, it was convincing businesses to abandon their current database (Oracle Database, SQL Server, or MySQL) in favor of us. There’s an old saying that goes, “Nobody ever got fired for choosing (insert big commercial database company name here.)” While I tend to think anyone who says that should probably be fired, I acknowledge that, when a company is looking to put all its eggs in one basket, it’s a big risk. Accordingly, companies want some social proof to boost their confidence in this type of decision.

Regardless of how good a product is, as a small business, it’s difficult to convince companies to accept this level of risk. EnterpriseDB struggled with this for a long time, which is why they started targeting smaller, unimportant, databases, and new development projects instead. Doing this, over the last 15 years, they’ve gained pretty good market traction. What I learned there, however, is that most companies don’t want a wholesale switch – they just want options. Janus is solely about options.

The Future of NEXTGRES
The Janus Database Compatibility System is a Postgres-based database system that represents the culmination of all my NEXTGRES efforts. The SQL Dialect Interface (SDI) has been integrated directly into Postgres and supports parsing almost the entirety of MySQL, SQL Server, and Oracle Database syntax. Similarly, the optimizing Universal Procedural Language Compiler was incorporated and supports a large subset of SQL/PSM, Transact-SQL, and PL/SQL. Lastly, the protocol support code has also been implemented directly within the database engine, which means there is no significant overhead caused by ODBC or as a man-in-the-middle proxy. The new system even supports a subset of the memcached, Redis, and MongoDB protocol and functionality. While it sounds as though this design is intended to replace a database–and it can be used that way–it was designed to act as a federated database system.

Not only do companies have data all over the place, on-prem and in the cloud, but also stored in several different databases. Janus builds upon Postgres’ enhanced foreign data wrapper interface to provide companies with a single point of access to their data, wherever it’s stored, in a way that is compatible with what they’re currently using. A really cool demo demonstrating the transparent use of Janus as a single interface to data stored in MySQL, Postgres, SQL Server, Oracle Database, TimesTen, eXtremeDB, Amazon Redshift, Amazon Aurora, and SQLite will be coming soon.

In short, while making one database look like another has been a fun career, it’s not where the market is going. The volume of data companies now retain requires a completely different focus – one that makes it easy for them to access that data wherever and however it’s stored. The future of the industry isn’t about which database is better than the other, it’s about using the right database for the job.

With Janus, companies are encouraged to choose whichever database they want – it will simply reduce friction and make it easier for their databases to work together. To me, that’s freedom.