EnterpriseDB will make its open source PostgreSQL relational database more attuned to a NoSQL world, with plans to add autosharding capabilities.
Speaking at this week's NoSQL Now conference in San Jose, Calif., Bruce Momjian, senior database architect at EnterpriseDB, talked about plans for the database, also known as Postgres. "In the next year or two, we're actually doing a major push to add auto-sharding to Postgres so that you can have dozens of Postgres servers all working in a unified way, sharing transactions, sharing workloads," he said. "So now, Postgres can take on the kind of workloads that historically only NoSQL can take on because it had multi-node capability." Postgres is limited in this fashion right now, he said.
Afterward, he elaborated on EnterpriseDB's intentions, citing an inevitable time at which Postgres must deal with large data sets. "With Postgres, we are getting to a point where we can't avoid addressing very large workloads," he said. "What we are planning to do as a community is develop autosharding. This will comprise of one central Postgres server that will take in the queries and know which shards are relevant and then push the query to the appropriate shard." EnterpriseDB and NTT have been working on this, he said.
The autosharding capability would not be Postgres' first recognition of NoSQL. The database added NoSQL-like JSON processing capabilities in 2012, and last year, the Postgres Extended Datatype Developer Kit was unveiled to allow developers to use the database for applications that previously required a NoSQL-only solution.
Momjian envisions Postgres acting as a central data broker within enterprises. He said he has no idea if Postgres would ever be as fast as a 100-node Apache Cassandra system, but he feels Postgres probably would have more capabilities than Cassandra. "Again, it's always a trade-off. How much performance do I need, how many features do I need, and where is the best technology for my particular choice?"
Foreign data wrappers could enable data to be left in Cassandra while being accessed from Postgres, which would provide relational and analytic capabilities, he explained; the database has supported foreign data wrappers for other data sources, including Oracle, MySQL, and MongoDB.