Citus Unforks from PostgreSQL, Goes Open Source (opens in new tab)

That's correct, and with such a significant license change I think the term 'unfork' is being used inappropriately in the title.

Edit: the PostGIS extension is GPL, and that license choice has been very successful. Hopefully the AGPL works out at least as well for Citus, I'm just not familiar enough to know what the implications will be in this context.

AGPL actually makes a lot more sense for a database (except for SQLite, which is typically redistributed).

Citus owns the copyrights, and the CLA ensures that they will continue to. That means that they can reassign it under a different license if they so choose, and they could at some point choose a liberal license.

No .. it means any changes you make to CitusDB should be made public.

[0] https://en.wikipedia.org/wiki/Affero_General_Public_License

No, it means if you make changes to the code and use it over a network you have to be AGPL too (think "network" as "distribution" in the GPL sense).

Would it be possible (eventually) to use Citus for sharding within the datacenter, and BDR for master/master replication between datacenters?

Or is Citus taking over the master/master replication? (or is it doing something different?)

What does "works well on the cloud" mean specifically? Is there some difference when run on your own hardware?

Can Citus handle geospatial sharding?

good work! congrats =)

also in Turkish: kolaylıklar dilerim :)

Excellent news! Really looking forward to this one! :)

I know Red Hat is making a ton of money. But, CoreOS and Docker, are they at the "making a ton of money" stage, or merely well-funded by investors?

Well, people use MongoDB...

AGPL only requires open sourcing any modifications you make to the software when you give users direct access to a server running the software, which seems like something you would never want to do in case of a database.

You can use database servers running AGPL software in a closed source SaaS: http://www.gnu.org/licenses/why-affero-gpl.en.html

If this costed roughly a million dollars, then yes. Especially if you're locked in like with a DB. I use nginx because even though it has this mode it would be easy to replace with something else.

(Part 3/3 - please see two comments below as the starting point) Aside from the different use-cases they address, there is one other, important difference between Citus and Redshift (and any other distributed database in the world, for that matter). Citus does not fork the underlying database, PostgreSQL. Instead, Citus extends PostgreSQL to transform it into a parallel processing, distributed database. We use PostgreSQL's powerful extension APIs to accomplish this (you simply CREATE EXTENSION Citus on PostgreSQL's latest version, 9.5, to get your distributed PostgreSQL database).

While this might appear as an implementation piece at first, it has important product implications, and might even impact how you might want to think about your database stack. By not forking the core database, you are choosing to always stay with the core PostgreSQL product. For starters, you get the uber-cool (and uber-fast) JSONB type that came with 9.4, or the recently checked in UPSERTs, or the popular PostGIS extension for geospatial capabilities. More philosophically, the moment you use forks of database, you know you'll be diverging over time. And when you introduce new databases and/or piece together many different ones to build one application, your development cycles will only get costlier and more complex over time.

This was a long answer to a short question, but hopefully useful. Let me know if you have questions, or any feedback using Citus – would love to hear your thoughts!

(Part 2) Now comes the storage engine, and cstore_fdw as it relates to PostgreSQL. Built by the Citus Data team, cstore_fdw is entirely a separate component from the Citus product above. It enables columnar storage for your vanilla, single-node PostgreSQL to provide data compression for faster analytics. As such, cstore_fdw does not come with any of the parallelism I've described above that Citus (or Redshift, Vertica etc.) provides.

Precisely because cstore_fdw is built for PostgreSQL, and Citus is PostgreSQL (see Part 3), however, you can still choose to use cstore_fdw as the storage engine for your Citus cluster. Citus will still parallelize the queries as you'd expect it to, but instead of hitting row- based tables, they will hit columnar ones. cstore_fdw has certain limitations, importantly it is not updatable; so we don't consider it as an alternative to a data warehouse. Rather, it is useful if you are archiving your quickly growing timeseries / event data on PostgreSQL or Citus.

Umur from Citus here. For purposes of this question, I’ll bucket traditional data warehousing (DWH) solutions like Redshift, Vertica, Greenplum together, although there are many nuances among each of them of course.

First, Citus is not a traditional data warehouse. We position Citus as the real-time, scalable database that serves your application under a mix of high- concurrency short requests and ad-hoc SQL analytics (i.e. think both random and sequential scans for a customer-facing analytics app). The default storage engine for Citus is the PostgreSQL storage engine, which is row-based. This is in contrast to many data warehouses, which often use a column store and/or batch data loads, and are focused purely on analytics. The trade-offs you get are: - Citus vs. DWH performance: DWH and Citus both have a similar parallelization for analytics queries (multi-core, multi-machine), but most data warehouses typically use a columnar storage engine instead of a row-based one. Columnar storage is designed for faster analytics queries, so that makes columnar DWH generally faster on longer running analytics queries. However, this comes at the expense of (1) concurrency and (2) short-request performance (think simple lookups, updates, real-time data ingest) vs. Citus' row-based storage. If you've tried having 10s of concurrent connections to Redshift for short lookups, or performing 100s/1000s of inserts/updates to power your application, these limitations will be familiar. This is to be expected, as Redshift is not designed as a real-time operational database, but an offline data warehouse.

In essence, the two classes of products are more complimentary than substitutes, even while they have some overlaps in their analytic capabilities. Something like Redshift will give you fast offline analytics, after you move your data in batch (via S3); Citus will directly power your analytic apps in real-time; without ETL'ing your event/user data back and forth between separate OLTP and OLAP databases. Both can be extremely fast: Redshift can run complex data warehousing queries that take an hour in a few minutes, Citus can scan and aggregate 100 million records in a few seconds, while simultaneously ingesting your events in real-time.

I hope that provides some clarification on the workloads. There is a lot more, including columnar storage and product approach (re: implications of extending Postgres 9.5 vs. forking Postgres 8.x), and I’ll dive into those in separate comments as well.

Are there any limitations you have run into? E.g. can you still use all index types that Postgres offers or are there any special distributed index types that CitusDB adds perhaps?

I guess if you're putting more servers in a rack, it does tend to be a vertically-oriented process. :)

It doesnt scale vertically either. Postgres is single-threaded meaning it can't make use of multiple CPU cores on the same machine. There have been some slow improvements to this and 9.6 seems to hint at some parallel aggregation changes but overall Postgres is strong in features but weak in scaling (in any direction).

Thanks for awesome product!

Do you know when you're planning to release Citrus 5.0 deb/rpm packages?

Does this mean that distributed transactions are not supported at all?

Ok, and what's the process like for disaster recovery with citus?

Since the move to open source, more recent upstream changes have been slowly merged in the code base, though they seem to be still on a 8.3 base, still a couple of years worth of code to go through.

A cute lemon logo might help :)

>> The BSDL does not make much economic sense to the company open sourcing their code

If this were true then Cloudera, Horton and a whole bunch of other companies would be out of business, yet in reality they are doing really well. All that AGPL is doing for Citus is:

1. Turning away people (customers) who are religious about licenses.

2. Eliminating any possibility of this code ever being integrated into PostgreSQL

So you take a BSDL codebase, fork it, close it, make proprietary changes, profiting from the BSDL codebase, then slap the PG community in the face by open sourcing it under a more restrictive license hoping to benefit from the community you just slapped in the face but restricting competition.

They are of course free to release their code under any license they wish. I just think releasing code under the *GPL when you profited from a liberal BSDL is a douche nozzle thing to do. But knock yourself out! This tells me all I need to know about the company.

Thanks. I went through it but couldnt find info about their cluster size, data size and queries response time

(Jason from Citus here)

Yes, that's what you're seeing right now, but in the past Citus (used to be "CitusDB") was a superset of the entire PostgreSQL codebase. During the lead-up to the open source release, we removed the use of any static methods or internal machinery and rewrote the installation process to use the PostgreSQL CREATE EXTENSION command. Additionally, we moved all of pg_shard's DML functionality into Citus to unify the product line.

So ultimately CitusDB was a fork but is now entirely an extension.

Yes, but Citus can also parallelize on multiple cores when used on a single machine ("If you’re running Citus on a single machine, this will scale queries across multiple CPU cores. and create the impression of sharding across databases."). Will this functionality becomes obsolete with the 9.6 ?