Get help on Discord

Using Sanity as middleware to edit database query results

5 replies
Last updated: Mar 29, 2022
I'm wondering if anybody uses Sanity as middleware, run some queries on a database during build time and then load results into sanity, so that users can make some manual edits like removing a few records of the results
AI Update

Yes, using Sanity as a "middleware" or curation layer is definitely a valid pattern! This workflow is exactly what you're describing: import data from an external database during build time, then let editors manually curate, filter, or enhance it in Sanity Studio.

How This Works

The pattern you're describing aligns with what Sanity calls a sync plugin approach. Here's the typical flow:

  1. Import external data from your database into Sanity as documents
  2. Editors review and curate the imported content in Studio (removing records, adding metadata, etc.)
  3. Your frontend queries the curated content from Sanity's Content Lake

Implementation Options

1. Sanity Connect Pattern (Automated Sync)

Sanity Connect is the official implementation of this pattern, currently available for Shopify. It automatically syncs external data and keeps it updated. The benefits are:

  • Single query to fetch all data from Sanity's API
  • Complete visibility of synced items in Studio
  • Editors can add custom fields, remove items, or enhance content
  • Two-way sync potential using GROQ webhooks

2. Custom Import Scripts (Build-Time)

For your specific use case with a custom database, you'd write your own import script:

Using sanity exec - Run scripts with authentication:

sanity exec scripts/import-from-db.js --with-user-token

Your script would fetch from your database and create/update documents in Sanity using the client API.

Using NDJSON import - Generate an NDJSON file from your database query results:

sanity dataset import data.ndjson production

The CLI migration tooling is ideal for this because it provides:

  • Automatic batching to avoid rate limits
  • Dry-run mode with visual feedback
  • Document validation against your schemas
  • Idempotent scripts you can run multiple times

Create a migration:

npx sanity@latest migration create

Editorial Workflow Benefits

This approach gives you the best of both worlds:

  • Structured data from your database
  • Human curation - editors can delete unwanted records, add editorial notes, attach images, or enhance descriptions
  • Single source of truth for your frontend - just query Sanity
  • Content modeling flexibility - add custom fields beyond what your database provides

Keeping Data Fresh

You can trigger re-imports on:

  • Build time - Run import script as part of your build process
  • Cron schedule - Periodic syncs using serverless functions
  • Webhooks - Trigger imports when source data changes (using Sanity Functions for event handling)

Practical Example

Many e-commerce teams do this with product catalogs: import products from their PIM/database, then let merchandisers curate which products appear on the site, add lifestyle images, write better descriptions, or remove discontinued items—all without touching the source database.

This pattern works great when you want your database to remain the system of record for certain data (like inventory or technical specs) while Sanity becomes the editorial/presentation layer.

Show original thread
5 replies
At present, it may make more sense to use the studio for more frequent user interactions. Calls to your external data can be built into studio forms. And it may be less admin intensive to manage users on the sanity side. Additional users and API requests can be added to all plans as well if needed.
Thanks User! I'm just getting started with learning how to create a schema. I am interested in learning how to pull in external content to studio forms, but can't find what to look for in the docs
This one may be easier than it seems. Try using initial value and nest the result from a custom component. In that component, put your external data query - then you can play with passing props into that function in your initial value.
If you want to calculate the value from external sources, try the default
slug type with a similar query component input - and then you can create a new document -> enter a couple fields -> and then use 
doc.field
to calculate the external query prop from one of your document fields - all this without having to create a custom input from scratch.
I’m not sure if onChange would work nicely with the default inputs. If you want to try it could be worth a shot, but if you’d like the query to update as you edit a field this may require a custom input component. I’d still try the built-in onSubmit within the default slug type first as proof of concept and to test the external query in the studio.
Thanks for all the info User! This is good news. My use case is for things like pre populating lists of items and allow users to delete certain items in studio, or let users enter in an item id and the rest of the data could be fetched from the db

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Get started for freeExplore the demo

Was this answer helpful?