Postgres-XL 9.5 R1 Beta1 Announced!

The Postgres-XL community is pleased to announce Postgres-XL 9.5 R1 Beta 1. Postgres-XL is a massively parallel database built on top of, and very closely compatible with PostgreSQL 9.5 and its set of advanced features. Postgres-XL is fully open source and many parts of it will feed back directly or indirectly into later releases of PostgreSQL, as we begin to move towards a fully parallel sharded version of core PostgreSQL. Postgres-XL is different because it supports both Business Intelligence and OLTP workloads in the same horizontally scalable server. This allows Postgres-XL to support a diverse range of workloads OLTP workloads that need write-scalability as well as read-scalability Business Intelligence requiring OLAP with massive parallelism Operational Data Store/ Central Data Backbone Distributed Key-Value store using JSONB, similar to NoSQL Internet of Things applications Mixed-workload environments Star schema style SQL queries exhibit large performance gains from massively parallel processing (MPP). Many queries show fully linear performance gains, for example a 16-node XL cluster is 16 times faster than PostgreSQL on one node. Postgres-XL is able to successfully complete the complex TPC-H business intelligence benchmark, showing its capability to address much more than basic operations. Postgres-XL’s High Availability functionality has also been enhanced in this release. Popular features such as BRIN indexes, JSONB and GIN index compression are fully supported, as are many popular extensions. Postgres-XL is available for download here: http://www.postgres-xl.org/download/ You can go through XL’s comprehensive documentation here: http://files.postgres-xl.org/documentation/index.html 2ndQuadrant has led the development of Postgres-XL 9.5, building upon the work of many others over a long period of continuous development, with easily more than 10 man years of development....

License Change and 9.5 Merge

The source code to Postgres-XL has now been changed from the Mozilla Public License to the more liberal PostgreSQL License. There is ongoing community work to merge PostgreSQL 9.5 into Postgres-XL, thanks to the contributions of 2ndQuadrant. The latest repository can be found here: git://git.postgresql.org/git/postgres-xl More updates will be coming...

Docker for Postgres-XL

Interested in using Postgres-XL with Docker? Matthieu Lagacherie and Yannick Drant have put together a docker container for testing: http://www.postmind.net/pgxl_docker-en.html

Learn about Postgres-XL in San Francisco on Aug 12

Come join us on August 12th to learn about Postgres-XL at the San Francisco Bay Area Meetup: SFPUG August: Postgres-XL Tuesday, Aug 12, 2014, 7:00 PM CloudFlare665 3rd Street, Suite 200 San Francisco, CA 81 PostgreSQL Users and Developers Attending Topic: Postgres-XL: Supersized PostgreSQLSpeaker: Mason SharpFood Sponsor: Translattice Inc.Host/Drink Sponsor: CloudFlare Inc.Location: TBD; Somewhere in San FranciscoPostgres-XL was recently released to further extend the open source Postgres ecosystem, allowing users to scale-out both transactional workloads and obtain fast response times… Check out this Meetup → Hope to see you...

Single Server Postgres-XL For PostgreSQL Parallel Query

You thought Postgres-XL was just a clustered solution? Postgres-XL works well on a single server for a data warehouse or reporting server. PostgreSQL is a fantastic multi-purpose database, but there is still no parallel query capability. What this means is, even if you have a 16 core server, your query is just going to use one single core while it processes that query, leaving the other 15 cores idle. Of course, if there are a lot of other concurrent sessions sharing resources, that may be acceptable. If there are very few, or automated reports that run, there are a lot of wasted resources. Instead, you could use Postgres-XL. Just install a GTM, a single coordinator, and multiple “datanodes” on the server, all running on different ports, and you have a one box cluster. Now when you submit a query to a coordinator, it will be parallelized and push down as much work as it can to the datanodes, getting more of those cores working and processing your queries faster. For even better performance, consider splitting the datanodes across multiple storage devices, instead of them contending for the same device. What about redundancy? You could setup each component to have a standby on another server, with a GTM standby, coordinator standby, and one datanode standby for each datanode on the primary server. Happy...