For most heritage projects the honest answer is not "Wikidata or a local database" but "both, for different jobs". Keep a local database as your authoritative system of record, where you control edits, store rights-restricted notes and run daily operations. Use Wikidata as a shared identity and linking layer to connect your collection to the wider web and enable cross-institutional queries. Choose Wikidata-only just for small, fully public reference datasets; choose local-only when control, privacy or stability outweigh discoverability.

What is the core difference in plain language?

A local database is a private filing cabinet: you own it, you control who edits it, and it does exactly what you tell it. Wikidata is a shared public noticeboard: anyone can read and edit, everything is open, and the payoff is that your facts connect to everyone else's. One optimises for control, the other for connection.

A second difference is identity. In your database, "London" is a row. In Wikidata, London is Q84, the same identifier every other contributor uses — which is what makes cross-collection linking possible.

A small worked example

Say you hold three medieval charters issued at York. In a local database you might have:

CREATE TABLE charters (
  id        INTEGER PRIMARY KEY,
  title     TEXT,
  place     TEXT,        -- 'York' as free text
  year      INTEGER
);

Your place column is a string. If a colleague at another archive writes "Yorke" or "Eboracum", queries will not join. On Wikidata the same charter links wdt:P1071 (location) to wd:Q42462 (York), a stable identifier shared globally — so a query can pull every charter issued at York across every contributing archive at once.

When should I prefer a local database?

Choose local control when:

• You need to store sensitive or rights-restricted information.
• You require guaranteed stability — no one else can alter your records.
• Your workflow needs custom fields, validation rules or transactions Wikidata cannot express.
• You are mid-project and not ready to make data public.

A local SQLite or PostgreSQL database is also simply faster for high-volume internal operations.

When does Wikidata win?

Choose Wikidata when discoverability and linkage matter more than control:

Goal	Better choice	Why
Cross-institution queries	Wikidata	shared identifiers
Public discovery / SEO	Wikidata	indexed, reused widely
Authority control reuse	Wikidata	links to VIAF, GeoNames, Getty
Sensitive data	Local DB	private and controlled
Stable system of record	Local DB	you are sole editor
Custom business logic	Local DB	full schema control

How do the two work together in practice?

The mature pattern is hybrid. Your local database stays the source of truth and holds everything, including private notes. You then push public, sourced facts to Wikidata and store the resulting Q-id back in your local record. Now your internal system gains a stable link to the global graph, and external users can discover your holdings — without you surrendering control of the master copy.

ALTER TABLE charters ADD COLUMN wikidata_qid TEXT;  -- the bridge

That single column is the bridge between private control and public connection.

What does a beginner most often get wrong?

The classic mistake is treating Wikidata as a free hosted database for everything, then panicking when an edit war or a deletion touches "their" data. Wikidata is a commons, not your private storage. The opposite mistake is hoarding everything locally and missing the discoverability that shared identifiers bring. Start hybrid: keep control where you need it, share what you safely can.

Key Takeaways

• It is rarely either/or — most projects run a local database of record plus Wikidata for linking.
• Local databases optimise for control, privacy and stability; Wikidata optimises for connection and discovery.
• Shared identifiers are Wikidata's superpower for cross-institution queries.
• Never put rights-restricted or sensitive personal data on the public, CC0 Wikidata.
• Bridge the two by storing the Wikidata Q-id back in your local record.
• Anyone can edit Wikidata, so you trade exclusive control for collaborative reach.

Frequently Asked Questions

Is Wikidata a replacement for my collections database?

No. Wikidata is best as a shared identity and authority layer that complements your internal database, not a replacement for it. Keep your system of record locally and publish or link selected data to Wikidata.

What data should never go on Wikidata?

Anything rights-restricted, personal data about living individuals without justification, or facts you cannot reference. Wikidata content is CC0 and publicly editable.

Can other people change my data on Wikidata?

Yes. Anyone can edit, which is a strength for collaborative authority control but means you do not retain exclusive control. A local database keeps you as sole editor.

Which is better for querying across institutions?

Wikidata, by far. Because everyone uses shared identifiers, a single SPARQL query can span many collections, something a siloed local database cannot do.

Do I need to choose only one?

No, and you usually should not. The common pattern is a local database of record plus Wikidata for shared identifiers, enrichment and public discovery.

Related reading

• How to Get started with Wikidata for heritage
• Model heritage items in Wikidata
• Wikidata vs local data quality
• Linked Open Data for heritage: an introduction
• SQLite for historical data