SuperScan Migrates from Neon to ParadeDB
When Neon (also known as Lakebase) announced it would retire pg_search, SuperScan migrated its product search database to ParadeDB Cloud, keeping its existing Postgres schema and queries without rewriting its application’s search logic.
Moving to ParadeDB let us keep everything in Postgres: the same schema, the same queries, no search cluster to run on the side. For a small team, that matters more than anything.
Laurent D., SuperScan
Overview
SuperScan is a French AI-powered price comparison and conversational shopping search engine. Shoppers describe what they need in plain language or scan a barcode, and SuperScan finds matching products and compares offers across merchants.
Behind that experience is a product catalog updated around the clock. The database holds about 306 million rows, including 44.6 million products and 55 million merchant offers, in 283GB of storage. The ParadeDB search index is 37GB.
Each conversational search generates a substantial query: 200–300 BM25 clauses spanning 12,000–17,000 characters, evaluated over the full product index. Meanwhile, three ingestion lanes run every two to five minutes, sustaining roughly 670 rows per second during a heavy ingestion night.
The Problem
SuperScan had built its product search on ParadeDB's pg_search extension, running inside its Postgres database on Neon. When Neon announced it would retire the extension on December 15, 2026, the team needed a new home for its database and search workload.
The deprecation put a deadline on that move. SuperScan's query builder already generated complex pg_search queries, and the team wanted to preserve that investment. Replacing the search engine would mean redeveloping a core part of the application, while moving search outside Postgres would introduce a separate cluster and synchronization pipeline to maintain.
The Solution
SuperScan needed a managed Postgres service running a current, actively maintained version of pg_search. It had to support the existing schema and query syntax so the team could move its database without rewriting the application's search logic.
The team considered staying on Neon with Lakebase, but that path would have required significant redevelopment. ParadeDB Cloud let SuperScan retain its Postgres architecture and existing pg_search query syntax. The team deployed it as its standalone primary database on a PDB-8 instance in eu-west-1, running PostgreSQL 18.
SuperScan moved over 200GB of data and cut over to ParadeDB Cloud in October 2026. The migration went smoothly, with its existing queries working without a rewrite.
Results
SuperScan completed the migration ahead of Neon's deprecation deadline, preserving its Postgres schema, query builder, and application architecture. Keeping the extension current became simpler too: on October 24, the team upgraded from pg_search 0.25.11 to 0.26.2 directly from the ParadeDB Cloud console.
The move also improved search performance. The BM25 portion of SuperScan's reference searches dropped to a consistent 0.4 seconds on ParadeDB, compared with 20–45 seconds on a cold cache or about 2.5 seconds with manual prewarming on Neon. For those searches, the database stopped being the bottleneck.
What made the difference is the team: when we hit an issue, we talked directly with the people who build pg_search, and we got answers and fixes, not tickets.
Laurent D., SuperScan
SuperScan now uses ParadeDB to support conversational product search with guided refinement, barcode-based price comparisons, and public product pages with price history, daily deals, and alerts. The same database also supports its product export to Google Shopping as a comparison shopping service.
The team continues to work with ParadeDB on keeping search latency stable under its heavy, continuous write load, with further measurements under sustained ingestion in progress.
ParadeDB
ParadeDB is the simplest way to add Elastic-quality search to your Postgres. If you have a use case around large-scale search in Postgres, try out ParadeDB Cloud or get in touch.