From: | SQL Padawan <sql_padawan(at)protonmail(dot)com> |
---|---|
To: | Ben Chobot <bench(at)silentmedia(dot)com> |
Cc: | Mladen Gogala <gogala(dot)mladen(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Database Scalability |
Date: | 2021-12-01 18:22:40 |
Message-ID: | _t8HMEZ0d_67otynMLlQsUo0UzyaOgqzPUWfcwTzb0MZbqZqt1DzHb8FfYj8AN5bOBQKi0LzroP81AlT3V2qniuJuxQrdtg9w_SyBH1y_6w=@protonmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> > To my knowledge PostgreSQL doesn't support sharding, which is well and
> >
> > good because sharding is mostly useless, at least in my opinion.
> Not only does PostgreSQL natively support table partitioning (which is
>
> absolutely a form of sharding), there multiple well-regarded extensions
>
> that can help with sharding, all of which are orthogonal to how you can
>
> configure your application to use Postgres in the first place. So to say
>
> Postgres doesn't support sharding is.... misleading, at best.
>
> Also, the general concept of sharding to move your scaling challenges
>
> from vertical ones to horizontal ones has multiple self-evident
>
> advantages. If your work history has all happened to fit on a single
>
> server, then bully for you, but not everybody has it so easy.
It supports partitioning out of the box - not sharding where different tables reside on different machines!
CitusData and TimescaleDB provide sharding as extensions - both of which appear useful for TimeSeries data. There was PostgresXL which was a general sharding (multi-machine) solution that appears to have died.
SQLP!
From | Date | Subject | |
---|---|---|---|
Next Message | SQL Padawan | 2021-12-01 18:37:37 | Pgcrypto extension - decrypt(encrypt(... not returning original data? |
Previous Message | Tom Lane | 2021-12-01 16:10:28 | Re: Linux: directory change .../lib to .../lib64 |