Database from the 1980s needs time travel says author

It's back to the future for PostgreSQL as Michael Stonebraker lists priorities for the popular open-source system he helped create

PostgreSQL co-creator and MIT computer science professor Michael Stonebraker has listed his top requests for features to add into the popular open-source database, including a time travel function he admits was implemented badly in the 1980s.

Speaking at Postgres Vision conference, Stonebreaker said the time-travel code was fundamentally a good idea, as it allows users to query data from the database’s history, and had introduced an implementation in the 1990s.

“The problem with time travel back in 1995 was that my implementation was absolutely awful. It was slow, slow, slow, slow. Whether or not time travel was a good idea, the implementation was too slow to be interesting, so it was rightfully deleted by the powers that be in the committee that has been dealing with Postgres since 1995,” he told attendees.

Postgres was first proposed in 1986 [PDF] as a successor to Ingres while Stonebreaker was a professor at UCL Berkeley. PostgreSQL is released under the OSI-approved PostgreSQL License. He received the 2014 Turing Award for introduction of the Type System, which still underpins PostgreSQL today.

Despite the earlier failed attempt, he said time travel would top of the list of features he would like to see PostgreSQL in the future. “It allows you to fix user application mistakes. Basically, it allows you to put in different terms that allows you to query the log, so if you want to know what happened yesterday, just set it to yesterday, and life is good,” he said.

Stonebraker added that time travel would have the side benefit of helping administrators analyze denial of service attacks, for example. The second thrust he wanted to see from PostgreSQL developers was to make software as a service a priority. While companies like Postgres service company EDB offered a platform as a service for PostgreSQL, taking some of the hassle away from running the system, the goal should be true SaaS, he said.

“With PaaS you have an instance on AWS or Google Cloud Platform and you pay for this instance, 24/7, until you delete it. That doesn't make your resource management problem any more efficient."

“I'm a huge fan of SaaS. You share some set of instances that somebody else worries about and that somebody agrees to charge you only when you use actual transactional services. This is obviously going to be cheaper if somebody else is worrying about allocation and time-sharing resources between you and other people,” he said.

However, PostgreSQL copies such as AWS Aurora had taken a lead on open-source PostgreSQL in this area, he added.

“The problem I see with SaaS is it is currently offered by some of the ‘cloud elephants’, Aurora, for example. In my opinion, PostgreSQL should be in this game, or it risks losing mindshare to the cloud knock-offs. More generally, the cloud is really the future of computing and PostgreSQL and EDB should be paying very, very careful attention to facilities that are desirable in this world,” the DB pioneer explained.

Third on Stonebrakers’ wishlist was data warehousing. Since the 1990s, data warehousing had been a market PostgreSQL had been missing out on, he said. The problem was, PostreSQL is a row-store database, whereas data warehousing application were best supported by column store databases, he said.

“Column stores are just more efficient than row stores when you're only searching a few fields,” he said, adding:

“PostgreSQL is not competitive in the data warehouse market. I've talked about this with various people in EDB and elsewhere, and [they] have consciously decided not to play because it's a lot of work. Getting a column store is essentially a new storage engine, a new executor and the new optimizer and that's a lot. I understand [the] decision. However, this is a big market."

The last request was to better support user-defined functions and stored procedures in PostgreSQL. He pointed out that computer scientists know it is better to run logic in a stored procedure, or user defined function in the database system, than bring the data to the application. But “real programmers don't use this stuff”.

Stonebraker described how a Stanford student conducted a survey of developers and found in the feedback that the stumbling points included no debugger, no versioning, no test environment, a lack of standards and a lack of language support.

“User-defined functions and stored procedures are a pain in the butt to get to production, because in development and debugging, they are really painful. So please, please, please PostgreSQL: you can fix the tooling for user-defined functions and stored procedures. You can implement debugger, it's not that hard."

With Stonebreaker still seen trailblazer in database software, maybe the community will listen to his views. Whether they will act is another matter. However, EDB, itself a major contributor to the project, has the resources to do so. It has just announced a new round of funding by Bain Capital Private Equity to fuel its future growth. ®

Similar topics


Send us news

Other stories you might like