icdt-topic-selection

name	icdt-topic-selection
description	Use when deciding whether a database-theory project belongs at ICDT (International Conference on Database Theory) or should be routed to PODS, the co-located EDBT systems track, a pure-TCS venue (LICS, ICALP, STACS), or a journal (ACM TODS, LMCS, TheoretiCS), and when distinguishing ICDT from its sibling database-theory flagship PODS by calendar, publisher, and community.

ICDT Topic Selection

Decide the venue before drafting. ICDT — the International Conference on Database Theory — is the European foundations-of-data-management venue, held jointly with EDBT and published open access in LIPIcs. Its referees read for a precise theorem with a clear consequence for data management: query languages, the complexity of query evaluation, finite model theory over databases, consistent query answering, provenance, and the theory of data integration. A technically strong paper whose real content is generic complexity theory, pure logic, or a systems benchmark is respected and then rejected as out of scope.

The routing question that matters most

ICDT and PODS are the two database-theory flagships and overlap almost completely in scope, so the decisive question is rarely "is this database theory?" but "which of the two theory venues, and which calendar and publisher, fits this paper now?" Both want a real theorem with a data-management payoff. Use the finer signals below and the live deadlines to choose.

Sibling-venue routing table

Signal in your project	Better home	Why
Foundational data-management theorem; you want European co-location and the next ICDT cycle is nearer	ICDT	Two-cycle LIPIcs venue with a Cycle-1 revision option; co-located with EDBT
Same kind of theorem, but PODS's single annual cycle lands better or you want the SIGMOD stage	PODS	The other database-theory flagship; ACM PACMMOD, co-located with SIGMOD
The contribution is a system, an algorithm with an experimental evaluation, or a benchmark	EDBT (co-located) or a systems venue	Experimental data management, not a theorem — the reproducibility track lives here
The core is generic finite model theory / logic with no data-management consequence	LICS / ICALP / STACS	EATCS/logic venues reward the theory itself; ICDT wants the querying/constraints payoff
The result is too long, or wants a full journal treatment with all proofs	ACM TODS / LMCS / TheoretiCS	Journals with no page ceiling; some are the natural home for the extended version
A neat connection between database theory and a neighboring field, short	ICDT "Database Theory in Action"	The 4-page non-anonymous track for bridging results and applications

What makes a paper ICDT-shaped

• A theorem about querying or data. A new expressiveness result, a tight complexity bound for evaluating a query language, a decidability/undecidability result for a class of constraints, a dichotomy — with the database-theory consequence stated, not implied.
• Matching upper and lower bounds where the field expects them; a one-sided bound is often a "revise," not an accept.
• A model that connects to data management. Finite structures, relational/graph/semistructured data models, incomplete or inconsistent databases, provenance semirings, integration mappings — the "database" in the name is load-bearing.
• Foundational or conceptual advances — a new framework, a semantics, or a proof technique that the data-management theory community can build on.

The two sharpening tests

• PODS-swap test: could this paper appear at PODS and read as native there? Almost certainly yes — so the choice is by calendar, publisher preference (open-access LIPIcs vs ACM PACMMOD), and community pull, not by scope. Pick the nearer honest deadline unless a specific reason favors the other.
• Consequence test: strip the data-management framing — is there still a database-theory lesson, or just a complexity/logic result? If only the latter survives, a pure-TCS venue fits better and ICDT referees will say the data connection is decorative.

Maturity, without the ladder cliché

An idea sits at different doors depending on how finished the proof is. A conjecture with partial evidence is a workshop or "in action" contribution, not a regular ICDT paper; a theorem with a gap you can close belongs in Cycle 1 where the revision option exists; a fully worked, book-length treatment belongs in a journal. Submitting a one-sided bound when the field expects a matching one costs a cycle.

Cheap reconnaissance before committing

[Scope]    scan the last two ICDT and PODS programs (dblp, databasetheory.org) for your subarea
           -> present at both = pick by calendar; present at neither = mismatch or a new opening
[Citations] is your bibliography majority ICDT/PODS/LICS/TODS/LMCS?
           -> majority systems venues => you may actually have an EDBT/SIGMOD paper
[Calendar] compare the next ICDT cycle deadline with the PODS deadline and journal timelines
           -> route to the nearest honest fit; ICDT's two cycles give you two shots a year

Decision procedure

[Consequence] who in data management cares if the theorem holds? -> real payoff or decorative?
[Claim type] expressiveness / complexity / decidability / semantics / framework
[ICDT vs PODS] both fit? -> choose by calendar, open-access LIPIcs vs PACMMOD, community pull
[Sibling check] systems+experiments -> EDBT; pure logic -> LICS/ICALP; over-long -> journal
[Verdict] ICDT regular track / PODS / EDBT / TCS venue / journal, with a one-line reason

Run this before the writing skills; a wrong venue decision wastes every later step. When the verdict is ICDT, continue with icdt-workflow for the two-cycle calendar and icdt-writing-style for the theorem-proof shape.