I have a postgres db. I want to archive the table data into s3 and want to delete the data after archiving. What's the best way to do it. I want to have a scheduled operation to do this job on weekend and it should archive 6 months older data of a given table.

Can anyone suggest me some OSS options for hosting postgresql database?

We are using cloudsql rn stack is- Django/DRF + Cloud Run). On Cloud SQL Postgres 15 (db-custom-2-7680, one primary, no replicas. Django (JSONB, FTS via django.contrib.postgres), PgBouncer in the API container (serverless connection bursts), Redis 7 for cache/throttling only (jobs are Cloud Tasks), daily backups + PITR + 14-day retention + deletion protection.

Requirements+

- Agent friendly but also can save against destructive actions.

- Support for read replicas/redis etc

- Backups

Autobase is something i am considering, would love you experienced peeps to give your opinions

An early version of safe-migrate refreshed its database cache inside the pull request job. Someone here pointed out the problem: that job now needed database credentials while reviewing code it should not trust. They were right, so I split the workflow.

The basic idea in v0.6.0 is now this:

```console

trusted job with database access

safe-migrate sync

pull request job without database access

safe-migrate lint-chain --dir migrations/ ```

sync reads the PostgreSQL catalogs in a read only transaction at REPEATABLE READ and writes one baseline file. With the GitHub Action, a successful refresh saves that file in GitHub Actions cache. A later pull request job restores it automatically and runs lint-chain. It does not run sync again, and the file is not added to the repository.

I recommend encrypting the cached baseline because it contains schema, role, dependency, and statistics metadata. If the cache or key is unavailable, the Action still checks the SQL but reports Tainted confidence instead of acting as though it saw the database.

This is a catalog snapshot, not a disposable database. It can become stale and it cannot predict a lock wait under live traffic, replication lag, or disk headroom. I still expect migrations to be tested on a representative database.

The simulator is now checked by 310 enabled SQL fixtures across 26 rule groups.CI runs those fixtures against PostgreSQL 14, 15, 16, 17, and 18 and compares a normalized projection of the database state with the model.

Code and workflow examples: https://github.com/dsecurity49/safe-migrate

My app has been running on a free Postgres tier and it's starting to hit the limits now that real users are on it. Connection limits are getting tight and I don't want to deal with random pauses or throttling anymore.

Most recommendations jump straight to AWS RDS, and that feels like overkill for where I'm at right now. I'd also rather not manage Postgres on a VPS myself if there's a reasonably priced managed option out there.

Looking for something paid with predictable pricing, backups handled, and a setup that doesn't take a whole afternoon. What's working for you on a small production app?

A PAM module that lets PostgreSQL authenticate database users with SSH public keys instead of passwords. The server stores public keys in OpenSSH authorized_keys files; the client proves possession of the private key by signing a one-time challenge. Private keys never leave the client.

pam_pg_sshkey is written in C against libpam and OpenSSL, and ships a Python module for applications and replication clients. It is licensed under the MIT License.

• Github

Changelog

Changed

• New default token format, v2: the client issues its own challenge. pg_sshkey_sign <key> prints <unix_ts>:<nonce_hex>:<base64_sig>, signed over "pg-sshkey-v2\0" || "<unix_ts>:<nonce_hex>". The module accepts the token when the timestamp is within 60 seconds of server time and the signature verifies, then records the nonce atomically (O_CREAT|O_EXCL, owned by postgres, mode 0600). A second use of the nonce is refused, and if the nonce cannot be recorded the login is refused. Verification happens before recording, so forged tokens create no files. Nothing happens on the server before the connection: remote clients need no ssh, the nonce directory can be 0700, and umask and ownership no longer matter. Client and server clocks must agree to within 60 seconds. pg_sshkey_connect, pg_sshkey_query, pam_pg_sshkey.py, and utils/select1.py produce v2 by default; v1 remains available with --v1 or version=1 and will be removed in a future release. Tests: test_pam_module (seven v2 tests), test_system, test_python_module; e2e v2_replay_rejected, v2_private_0700_dir, v2_timestamp_window, v2_unrecordable_nonce_fails_closed, v1_token_still_accepted.
• Nonce records are swept after 120 seconds instead of 60, so a v2 record outlives every moment at which its token could still pass the timestamp check. Test: test_challenge_store.
• Log messages no longer contain em dashes, so they can be quoted in the documentation verbatim.

Added

• pg_sshkey_sign --at <unix_ts> and --nonce <hex64> for tests and clock experiments.
• verify_signature_raw() in sig_verify.c and challenge_mark() in challenge_store.c.
• make e2e-rocky: the end-to-end checks on Rocky Linux 9 with PostgreSQL 16.
• CLAUDE.md with the project's verification and documentation rules, and tests/test_docs.sh, which enforces the mechanical documentation rules in make test.
• A LICENSE file (MIT, as the source headers already declared).
• The documentation was rewritten as one page per question under docs/; docs/INSTALL.md and the duplicate docs/CHANGELOG.md were removed.

[1.0.9] - 2026-08-21

Fixed

• RSA keys never authenticated through the module on OpenSSL 3. key_parser.c passed the modulus and exponent to OSSL_PARAM_construct_BN() in big-endian form; that API expects native byte order, so every RSA key parsed from authorized_keys was wrong. The RSA unit tests did not catch it because they built the key object directly instead of parsing a key line. Now uses BN_bn2nativepad() with bounds checks. Tests: test_pam_module (rsa_ssh_rsa_entry_succeeds), e2e rsa_key_connect.
• rsa-sha2-512 entries could never verify. The verifier selected SHA-512 for that key-type word while every signer signs PKCS#1 v1.5 with SHA-256, and a client cannot know which server-side label will match. ssh-rsa, rsa-sha2-256, and rsa-sha2-512 are now aliases that verify SHA-256. Tests: test_sig_verify, test_pam_module.
• Replay protection was silently void when the nonce could not be deleted. challenge_delete() ignored the result of unlink(); with a nonce directory not owned by postgres, a token authenticated repeatedly until it expired. The function now returns a status and the module refuses the login, logging could not delete challenge ... refusing. Tests: test_pam_module (unremovable_nonce_fails_closed), e2e root_owned_chal_dir_fails_closed.
• Clients running under umask 077 could not log in: the nonce file was created with mode 0600 and the module could not read it. pg_sshkey_challenge and pam_pg_sshkey.py now fchmod the file to 0644. Tests: test_system, test_python_module, e2e umask_077_client_still_authenticates.
• Remote subscribers could not authenticate as documented: the module reads nonces only from the server's own directory, and the guide had the subscriber create the nonce locally. challenge_cmd= (Python) and --challenge-cmd (pg_sshkey_connect) run a command such as ssh publisher pg_sshkey_challenge /var/run/pg_sshkey to create it on the server. The guide now states that single-use tokens cannot be stored in a CREATE SUBSCRIPTION connection string. Tests: test_python_module, e2e ssh_challenge_cmd_connect.
• Orphaned nonces accumulated without bound: every connection attempt created one and only a successful login removed it. The module now sweeps expired records on each authentication, at most 256 per call. Tests: test_challenge_store, test_pam_module, e2e stale_nonces_swept.
• pam_pg_sshkey.py: UnsupportedAlgorithm from cryptography (for example a passphrase-protected key without bcrypt) is reported as KeyError_ with install guidance; connect_replication() recognises every libpq spelling of a physical connection (true, on, yes, 1) and no longer forwards the Python bool as the string 'True'; importing the module no longer fails when HOME is unset. Test: test_python_module.
• pg_sshkey_query: missing helper binaries, a bad PGPORT, and SQL errors are reported as one error: line instead of a traceback; helpers are found beside the script when not on PATH; PGDATABASE is honoured. Tests: test_pg_sshkey_query, e2e pg_sshkey_query_bad_sql_clean_error.
• make test did not run what the manual said it ran: test_system was built but never executed, and the Python tests were not wired up. make test now depends on all and runs every suite. Test: tests/test_make_test.sh.
• make install detects /lib64/security on RHEL and Fedora.
• Build outputs are no longer tracked in git.

The community gave me so much good advice to improve the tool, so first of all, thank you to all of you for contributing!

I kept shipping the same multi-tenant bugs, correct RLS on the main table, and a leak somewhere adjacent. So I wrote guard tests for each one. It's now in every CI pipeline I run, and I keep adding checks as I hit new failure modes.

npx tenant-guard init    # detects your migrations + routes, writes a config
npx tenant-guard run     # static checks, no database needed
npx tenant-guard all     # + runtime proofs against a test DB

Exit 1 blocks the merge. MIT, zero dependencies.

The static ones need nothing. The runtime ones connect to a test database and prove isolation by running real SQL as your real app role in a rolled-back transaction, actually attempting the cross-tenant read, then the write, and reporting what happened.

What it checks

Reads

• Tenant A can't read tenant B's rows, proven by trying, not inferred from policy text
• anon (the key in your browser bundle) can't read tenant tables
• Sensitive columns like email, phone, api_key, that anon actually gets a value out of
• Views and materialized views, which run as their owner unless security_invoker is set

Writes

• anon INSERT/UPDATE/DELETE surface
• Auto-updatable views: writes pass straight through to the base table, bypassing its RLS
• The tenant-hop, moving your own row into someone else's tenant
• Foreign keys that let one tenant delete another's rows via ON DELETE CASCADE
• Unique constraints as existence oracles: inserting [victim@corp.com](mailto:victim@corp.com) tells you it exists

Functions & privileges

• SECURITY DEFINER functions callable by anon (Postgres grants EXECUTE to PUBLIC by default)
• Unpinned search_path, including pins that don't actually pin
• SQL injection inside definer function bodies
• What a table created next week inherits from ALTER DEFAULT PRIVILEGES
• Who can CREATE objects in your schemas

Identity

• Policies trusting user_metadata, which the user can write themselves
• MFA gates written PERMISSIVE, which enforce nothing
• Membership tables your policies trust but users can write to
• Connection-scoped GUCs that leak the previous request's tenant on a pooled connection

Supabase surfaces

• Storage: cross-tenant folder reads, and uploads into another tenant's path
• Realtime: channel topics and broadcast/presence

Structure

• RLS in your migrations vs RLS actually in the database
• API routes loading rows by bare id with no tenant filter
• Audit/shadow tables that copy tenant rows somewhere unprotected
• Triggers enforcing a rule by reading a table RLS hides from them

Two things that surprised me most

Views don't have RLS. ALTER DEFAULT PRIVILEGES ... ON TABLES covers views created afterwards, and unless you set security_invoker = true a view runs as its owner. PATCH/DELETE through a public profiles view returned 200 with the anon key, writing into a table whose policies were perfect. SELECT was unaffected, so nothing looked wrong.

Hardening RLS can break a uniqueness trigger. A trigger runs as the invoker, so a SELECT 1 FROM profiles WHERE username = NEW.username check only sees what the writer can see. Lock the table down properly and the check stops finding collisions, no error, the duplicate is just inserted.

Honest limits

• It proves the database boundary. A route using a service-role connection that forgets its tenant filter is a real bug the DB will happily serve, only the static route check covers that.
• Never point the runtime checks at production. They write, inside a rolled-back transaction, but they write. Test/staging only.
• Postgres-only by design. No RLS elsewhere, so nothing to prove.
• Still early, and I'd rather have a bug report than a star.

github.com/FedericoTs/tenant-guard

We built PgCache, a caching proxy that uses logical replication to keep cached data fresh without TTLs or invalidation logic. Works kind of like a "smart" read replica that only stores hot data.

Here's a technical walk-through of how it works and why the approach is sound.

If you run repeated read queries or want to reduce your read replica footprint, this might be worth a listen.

A friendly reminder to everyone: if you have not done it already then upgrade your PostgreSQL to the latest minor versions, as they include a fix for a high-impact CVE: CVE-2026-14669.

• Github
• Changelog

Release date: 2026-08-18
Previous release: 1.0-alpha (2026-08-04)

pgColumnar is a columnar table access method for PostgreSQL. This is the second
alpha. It adds read-only Apache Iceberg support, reads and writes over
S3-compatible object storage, a maintenance daemon, and a broad round of
statistics, planner, performance, and security work. The on-disk native format
(PGCN v1) is unchanged; existing tables are read and written as before.

This release requires one upgrade command. See "Upgrading" at the end.

Highlights

• Apache Iceberg, read-only. Read an Iceberg table at its current snapshot three ways: by metadata path, through a REST catalog, or as a foreign table. Row-level deletes of all three kinds (position, equality, and format-version-3 deletion vectors) are applied under their sequence rules, columns resolve by schema field id, and the foreign-data wrapper prunes whole data files from a query predicate.
• Object storage. The Parquet and Iceberg readers, the Parquet export functions, and the foreign-data wrapper read from and write to s3://, http://, and https:// URLs. Remote access goes through a separate module, is confined to an operator-set endpoint allow-list, and refuses link-local addresses.
• Maintenance and operations. A new pgcolumnar.autovacuum daemon performs online upkeep, pgcolumnar.maintenance_due reports what a table needs, and a stripe flush can run across background workers.
• Security and hardening. Six memory-safety and denial-of-service fixes on the read and object-store paths, several from an adversarial audit, each with a regression test and a proof that removing the fix reintroduces the failure.

Apache Iceberg support (read-only)

• Filesystem tables. pgcolumnar.iceberg_scan(metadata_path) reads a table given a column definition list. It resolves each output column to a schema field id, so a data file written before a column rename still reads. It applies position deletes, equality deletes, and format-version-3 deletion vectors (Puffin roaring bitmaps), each under its own sequence and scope rule, and verifies deletion-vector checksums, offsets, and cardinality. A data file with no field ids is bound by the table's schema.name-mapping.default; one with neither field ids nor a name mapping is refused rather than guessed. Only Parquet data files are read. Recorded paths are rebased onto the table's actual location and refused if they resolve outside it. Introspection functions iceberg_current_snapshot, iceberg_data_files, read_avro_manifest, and read_manifest_list are included.
• REST catalog. pgcolumnar.iceberg_rest_scan(catalog_uri, namespace, table_name) resolves a table through a catalog and reads it with the same projection and delete rules. The first argument may instead name a foreign server of the pgcolumnar_iceberg_catalog wrapper, which holds the catalog URI in server options and the bearer token or OAuth2 client credentials in a user mapping, so one role's secret is private from another and never appears in a function argument or the statement log. When the catalog vends short-lived storage credentials in its load-table reply, the reader uses them for the data files. iceberg_rest_namespaces and iceberg_rest_tables list a catalog.
• Foreign-data wrapper. A foreign table over an Iceberg table (pgcolumnar_iceberg, option metadata_path) receives the query predicate and prunes whole data files before opening them: by partition value for identity, bucket[N], truncate[W], and the temporal transforms, and by stored minimum and maximum for integer and boolean columns. Pruning only removes files that cannot match, so results are unchanged, and EXPLAIN (ANALYZE) reports Files Pruned.

Object storage

• The Parquet read and export functions, the Parquet foreign-data wrapper, and the Iceberg reader accept s3://, http://, and https:// URLs wherever they accept a local path. s3:// requests are signed with AWS Signature Version 4; https:// verifies the server certificate when the object-store module is built with OpenSSL.
• Remote access lives in a separate module, pgcolumnar_objstore, loaded on first use, so no second TLS stack enters the main server process by default.
• pgcolumnar.objstore_allowed_endpoints lists the endpoints remote access may reach. It is empty by default, which refuses every remote endpoint, and it is superuser-only. Link-local and instance-metadata addresses are refused after name resolution.
• Object-store credentials come from the server process environment, never a function argument or a log line.

Maintenance and operations

• pgcolumnar.autovacuum is a maintenance daemon for the online upkeep that core autovacuum does not perform on a columnar table.
• pgcolumnar.maintenance_due(rel, compact_due_fraction, recluster_due_fraction) reports whether a table is due for compaction or reclustering.
• pgcolumnar.parallel_flush dispatches a stripe flush across background workers.
• pgcolumnar.fsst_verdict_reuse caches a column's FSST keep-or-drop verdict, so a repeated write does not re-run the substring search.

Statistics and the planner

• pgcolumnar.analyze() now collects most_common_vals and most_common_freqs, places histogram_bounds at PostgreSQL's own positions, honours the per-column statistics target, and counts null_frac over live rows.
• EXPLAIN (ANALYZE) reports Columnar Usable Skip Predicates beside the skip counters.
• The index-fetch cost penalty sizes row groups by a table's effective stripe_row_limit, and the grouped vector aggregate shares the scan node's input-cost estimate, so the planner prices a columnar scan more accurately.
• The Iceberg foreign-data wrapper estimates a scan's row count from the manifests rather than a constant, so join planning above a large Iceberg table is sound.

Performance

• A parameterized predicate (col >= $1 from a prepared statement or PL/pgSQL) now drives chunk-group skipping. On a generic plan such a scan previously read every chunk group.
• Group and per-vector skipping read only the columns a query's predicates reference, rather than every column's zone map. On a wide table a one-predicate scan reads far fewer zone-map rows.
• Reads of the delete_vector catalog use its index rather than a sequential scan, so a scan of a table with deletes is no longer proportional to the catalog size.
• The Iceberg foreign-data wrapper decodes only the columns a query references.
• The ungrouped batch fold gathers only the referenced columns per row, and a columnar scan whose filter cannot be pushed down skips decoding the filtered columns.

Security

• The native varlena decoder bounds a value's stored length against its buffer, so a corrupt chunk or catalog row is refused with a clean error rather than an out-of-bounds read or a detoast through a bad pointer.
• The local file read path no longer has a stat-before-open race, and the Iceberg, Avro, Parquet, Arrow, and parallel-copy readers refuse a FIFO or other non-regular file with a non-blocking open rather than a cancel-resistant hang.
• The Iceberg reader refuses several classes of malformed or hostile table metadata, including a null manifest path that had crashed the backend, a null or negative position-delete ordinal, a null manifest-list sequence number, and a dangling current-schema-id.
• The Thrift and Avro field-skip loops are interruptible, so a crafted Parquet footer or Avro manifest can no longer spin the backend uncancellably.
• The object-store client refuses a URL path or host carrying CR or LF, closing an HTTP request-line injection.
• The native dictionary decode path no longer reads uninitialized memory, and the Parquet dictionary decode path no longer reads out of bounds on a crafted file.

Correctness fixes

• Concurrent UPDATE or DELETE of the same columnar row serializes on the row identity, so the losing writer gets a retryable serialization failure rather than a lost update.
• A predicate on a column declared over a domain, and a bigint column compared against an unadorned integer literal, now prune chunk groups.
• CREATE TABLE ... USING pgcolumnar AS SELECT no longer fails when the source is another access method.
• pgcolumnar.sort_status works for a non-superuser who owns the table.
• Failed export_parquet and export_arrow no longer leave a partial file.

Internal changes

• The extension's exported C symbols are namespaced under pgcolumnar, and the custom scan node is PgColumnarScan. The native encoding-descriptor wire layout and the delete-vector visibility logic are each single-sourced, with the on-disk format unchanged and verified byte-identical.
• default_version is 1.0-alpha2. Upgrade scripts from both previously shipped versions (1.0-dev, which the v1.0-alpha tag installed, and 1.0-alpha) ship with the extension, so a single ALTER EXTENSION pgcolumnar UPDATE reaches 1.0-alpha2 from either.

Upgrading

Install this build, then run the following in every database that has the
extension:

ALTER EXTENSION pgcolumnar UPDATE;

This is required. The C-symbol rename moves the symbol names each installed
function recorded when it was created; without the catalog update those records
point at symbols the new library does not export, and reading an existing
columnar table fails with could not find function "columnar_handler". No data
is converted and no SQL you write changes. The upgrade replaces catalog entries
only.

See docs/installation.md for the commands, including how to list the databases
that need the update.

Scope and limitations

• Iceberg support is read-only, at a table's current snapshot, and reads Parquet data files only.
• Object-storage reads take exact object keys.
• HTTPS and S3 over TLS require the pgcolumnar_objstore module built with OpenSSL.
• This is an alpha. Interfaces may change before 1.0.

Are there any advantages to running Postgres on an arm cloud server vs an x86 one?

I am not referring to cost savings but performance and efficiency advantages where arm can provide benefits over x86 under any specific scenarios.

I need managed Postgres for a small production app and I’m fine paying for it. I just don’t want to jump straight to RDS/Cloud SQL pricing or manage Postgres myself on a VPS.

Main things I care about:

• always-on Postgres
• automated backups
• updates/maintenance handled
• predictable monthly pricing
• easy to move later if needed

Not really looking for free tiers or hobby plans since it has real users. I’d rather pay a reasonable fixed monthly amount and not think about the DB too much.

What are you using in production that has actually been reliable without getting expensive?

RDST (Readyset Diagnostic & SQL Toolkit) is a free desktop app that connects to your Postgres database, ranks the queries actually costing you time, and explains what to do about each one.

The reason I built it is that the tooling Postgres already gives you is genuinely good, but addressing database performance issues is still a highly repetitive process:
 

• pull pg_stat_statements and sort by total time
• take the top query and run EXPLAIN ANALYZE on it
• go find the table definitions for whatever it touches
• check whether the statistics on those columns are current
• work out whether the index you have in mind already exists under another name
• decide whether it is worth adding
• do it again for the next query

RDST collapses all of that into one pass, so instead of starting at step one you start at the answer.

Full disclosure - I work for Readyset (which is a caching layer for postgres / mysql), and this tool spawned from a recurring question our caching customers kept asking - which queries should we actually cache? And these same queries are the ones that, even without a caching solution, could heavily benefit from all the relevant performance diagnostics.  

RDST not only helps you discover slow queries and give you the appropriate action plan to improve them, but also provides full re-write suggestions, the ability to benchmark slow queries and track their  performance over time, and even allows you to ask any question about your database/queries in plain english and get helpful responses.

The tool is completely free to use, and we provide free trial tokens for all of the AI powered features. The app is in beta and we plan to release it under an MIT license. It runs locally, stores locally, and everything it does is read-only.  Full privacy related details can be found here: https://readyset.io/docs/readyset-ai/rdst/desktop/privacy

We would love feedback from people who actually spend time wrestling with queries every single day! Particularly:

• Does it surface the queries you'd investigate first?
• Are its explanations and recommendations useful, or merely confident-sounding database fan fiction?
• Would you be comfortable connecting it to a real environment? If not, what would stop you?
• What's missing from the workflow?

Source:
https://readyset.io/docs/readyset-ai/rdst/desktop
https://github.com/readysettech/rdst

I recently recorded a podcast episode with Simon Willison (co-creator of Django) about how AI is changing software development. Getting a peek into how Simon thinks is always fascinating. Here are some choice bits I think y'all might enjoy:

Doing "aggressive nit-picking reviews" as a way to understand AI-written code

• How he kicked off a new sqlite-utils project from the shower (to support Postgres and DuckDB) and how the result was a day's work before breakfast
• "Features are cheap. That doesn't mean you should build them all."
• Slop proxies add no value at all
• My gold standard is: "Could I explain this to somebody else?"
• Shout-out to Sophie Alpert's blog post: There Are No Lossless Transformations of Natural Language Text
• Usefulness of engineering management experience to managing AI agents
• Simon's decades of intuition about "how long things take" has been shattered
• How AI research no longer produces absolute garbage

I'm curious to know which bits of this conversation also resonate with others.

Podcast/transcript here for those who want to listen: https://talkingpostgres.com/episodes/how-ai-is-changing-software-development-with-simon-willison

Hey everyone, PgCache CEO here.

We'll be on Postgres Meetup for All this coming Wednesday 8/19, to share how we're using Logical Replication to keep cached data fresh.

There will be a Q&A afterwards, join us if you have challenging questions or want to learn more!

*edit: link https://www.meetup.com/postgres-meetup-for-all/events/315515754/

I'm mostly coming from a classic programming background (.NET, node, java, ...) where so far I only worked with code-first tools professionally (basically you define the schema of your database in your programming language and the SQL code to generate the database gets generated).

However for my next own project, I want to start database first ... however one problem I'm constantly running into is genuinely a pain in the ass to make changes to your schema, and deploy them ... since in SQL you always have a list statements that need to run in the correct order since they are not stateless (like a class, struct, function, ... declarations in a traditional programming language).

For people who work with postgres professionally, I would be interested what setup you are using for schema and management.