Vitesse X – A PostgreSQL extension module for faster queries

Vitesse means speed in French :)

It is not intentional. :-)

It's quite refreshing to see that it explicitly calls out data types not supported.

Check out the Tech and Company pages as well as the slides from the recent South Bay PostgreSQL Meeetup: http://goo.gl/Mtg2W6

The founders both have strong academic and commercial experience and the advisor is Prof. Joseph Hellerstein (he has both an excellent academic reputation and good experience in industry/tech transfer).

Note that TPCH is a "decision support benchmark". There are other technologies for helping postgres with these workloads as well: a column-store approach like https://github.com/citusdata/cstore_fdw, or the recent work on parallel sequential scans in Postgres core (http://rhaas.blogspot.com/2015/03/parallel-sequential-scan-f...), etc.

Did you bother to click on any of the links, or did you just glance at the "news" page? Almost half of the links on the page ("technology", "check it out", "100% Postgres, 100X Faster for Analytics", or "(slides)") they explain how it works (and it makes sense, although I'd personally be very wary of installing this, due to not particularly trusting that it gets the implementation "correct").

The 8x improvement is somewhat misleading as it is based on a single TPC-H query. The other queries from the benchmark seem to show a ~3x improvement: http://vitessedata.com/technology

Given that their query engine uses an LLVM JIT compared to the standard PostgreSQL interpreter, these results are very reasonable. This is similar to comparing an interpreter vs a JIT for a programming language.

Even with the best intentions, benchmarking a database is notoriously difficult. I work on Presto, a distributed analytic SQL database, and we are often asked how it compares to other systems, or how it will perform for a given workload. The answer is always "try it and see", both because how it performs for your configuration and workload is the only thing that matters, and because there are so many variables that factor into the result.

> Why would some random software be able to make my pg 8 times faster or more?

Peter Boncz (creator of VectorWise, HyPer) says it best here: http://www.tpc.org/tpctc/tpctc2013/slides_and_papers/005.pdf

Remember also that the postgres planner and execution machinery is ANCIENT. Plan scoring still assumes Disk I/O = 10 MemoryAccess = 100CPU instructions. Modern CPUs are SIMD and Vector processing, but PG planning/exec machinery isn't vector aware. There's a 200X difference between L1 cache and main memory access that the PG planner can't see. And what about SSDs and NVMe vs disk? Spark gains its speed through caching intermediate result sets along with the ability to reconstruct them. But postgres doesn't cache intermediate results or query plans last I checked. Plus a million other things.

Postgres is wonderful, but not because it has natively fast analytics. 8X is nothing. 180X is better, but not as fast as Vertica, Aster, Greenplum, et al. I say kudos to Citus and Vitesse for leading the way.

> Why would some random software be able to make my pg 8 times faster or more?

I think we've already seen plenty of evidence that for OLAP type queries, there is a TON of room available for improvement vs. off the shelf PostgreSQL.

probably not snake oil; and 180x faster on tpch-1 is no where near physics speed. but these guys are just starting out. i'm sure they will go even faster once they pull out the stops.

the nice thing about their model is that it's a pure accelerator play. plug it in and go faster, pull it out, or replace it with something else. in theory, there should be no change to the application/query layer. It should be as simple as entering "create/drop extension vitessedata;"