Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Cold shape requests are slow when PostgreSQL has higher network latency

Open
  • Is something wrong?
#4,828 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
elixir, postgresql
Domain
databases, performance

Research direction

Start with the display_settings/0 implementation in the referenced Electric module and snapshot_query.ex, where the issue says Postgrex.query! runs each setting separately. Trace the snapshot transaction and compare cold request latency with the reproduction against a higher latency PostgreSQL connection. The suspected cause is unconfirmed; done means establishing whether combining the settings reduces sequential database calls and cold request latency.

Written by the indexing model from the issue text.

Description

triage

I was testing Electric 1.8.1 and seeing a noticeable difference in cold shape request latency depending on how close Electric is to PostgreSQL. Database is hosted on Neon cloud.

  • Local Electric → PostgreSQL (~60ms DB latency): request takes around 1.5 seconds
  • Electric deployed closer to PostgreSQL (~20 ms DB latency): request takes around 300 ms

Warm requests return in a few milliseconds.

Reproduction

  1. Run Electric against PostgreSQL with noticeable network latency.

  2. Request a new shape with offset=-1 and a previously unused filter value:

    curl -sS -G 'http://localhost:3000/v1/shape'
    --data-urlencode 'table=public.example'
    --data-urlencode 'offset=-1'
    --data-urlencode 'where=run_id = $1'
    --data-urlencode 'params[1]='
    --output /dev/null
    --write-out 'TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n'

  3. Repeat with different filter values to measure cold requests, then repeat the same requests to compare warm responses.

Suspected cause

The snapshot setup appears to make several sequential database calls, so network latency could account for a significant part of the delay.

Trace for a request that took 1.33s shows that span shape_snapshot.set_display_settings took 595ms, and shape_snapshot.query_fn took 414ms.

In particular, display_settings/0 in postgres.ex (https://github.com/electric-sql/electric/blob/%40core%2Fsync-service%401.8.1/packages/sync-service/lib/electric/postgres.ex) defines five statements:

SET bytea_output = 'hex';
SET DateStyle = 'ISO, DMY';
SET TimeZone = 'UTC';
SET extra_float_digits = 1;
SET IntervalStyle = 'iso_8601';

snapshot_query.ex (https://github.com/electric-sql/electric/blob/%40core%2Fsync-service%401.8.1/packages/sync-service/lib/electric/postgres/snapshot_query.ex) executes these through an Enum.map, calling Postgrex.query! separately for each statement inside the snapshot transaction.

Could these settings be applied in one database call, for example using a single SELECT with multiple set_config calls? I haven't tested that yet, so this is only suspected, not confirmed.

Dominant language
TypeScript
Stars
10.4k
Forks
394
Avg merge
22h 11m
Merged PRs (30d)
5

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from electric-sql/electric

All issues in electric-sql/electric

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.