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.
Source: brycewang-stanford/Awesome-Journal-Skills → ICDT-Skills/skills/icdt-topic-selection/SKILL.md
1---2name: icdt-topic-selection3description: 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.4---567# ICDT Topic Selection89Decide the venue before drafting. ICDT — the International Conference on Database Theory — is the10**European foundations-of-data-management** venue, held jointly with **EDBT** and published **open11access in LIPIcs**. Its referees read for a **precise theorem with a clear consequence for data12management**: query languages, the complexity of query evaluation, finite model theory over13databases, consistent query answering, provenance, and the theory of data integration. A technically14strong paper whose real content is generic complexity theory, pure logic, or a systems benchmark is15respected and then rejected as out of scope.1617## The routing question that matters most1819ICDT and **PODS** are the two database-theory flagships and overlap almost completely in scope, so20the decisive question is rarely "is this database theory?" but **"which of the two theory venues,21and which calendar and publisher, fits this paper now?"** Both want a real theorem with a22data-management payoff. Use the finer signals below and the live deadlines to choose.2324## Sibling-venue routing table2526| Signal in your project | Better home | Why |27|---|---|---|28| 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 |29| 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 |30| 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 |31| 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 |32| 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 |33| 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 |3435## What makes a paper ICDT-shaped3637- **A theorem about querying or data.** A new expressiveness result, a tight complexity bound for38 evaluating a query language, a decidability/undecidability result for a class of constraints, a39 dichotomy — with the database-theory consequence stated, not implied.40- **Matching upper and lower bounds** where the field expects them; a one-sided bound is often a41 "revise," not an accept.42- **A model that connects to data management.** Finite structures, relational/graph/semistructured43 data models, incomplete or inconsistent databases, provenance semirings, integration mappings —44 the "database" in the name is load-bearing.45- **Foundational or conceptual advances** — a new framework, a semantics, or a proof technique that46 the data-management theory community can build on.4748## The two sharpening tests4950- **PODS-swap test:** could this paper appear at PODS and read as native there? Almost certainly yes51 — so the choice is by **calendar, publisher preference (open-access LIPIcs vs ACM PACMMOD), and52 community pull**, not by scope. Pick the nearer honest deadline unless a specific reason favors the53 other.54- **Consequence test:** strip the data-management framing — is there still a database-theory lesson,55 or just a complexity/logic result? If only the latter survives, a pure-TCS venue fits better and56 ICDT referees will say the data connection is decorative.5758## Maturity, without the ladder cliché5960An idea sits at different doors depending on how finished the proof is. A conjecture with partial61evidence is a workshop or "in action" contribution, not a regular ICDT paper; a theorem with a gap62you can close belongs in **Cycle 1** where the revision option exists; a fully worked, book-length63treatment belongs in a **journal**. Submitting a one-sided bound when the field expects a matching64one costs a cycle.6566## Cheap reconnaissance before committing6768```text69[Scope] scan the last two ICDT and PODS programs (dblp, databasetheory.org) for your subarea70 -> present at both = pick by calendar; present at neither = mismatch or a new opening71[Citations] is your bibliography majority ICDT/PODS/LICS/TODS/LMCS?72 -> majority systems venues => you may actually have an EDBT/SIGMOD paper73[Calendar] compare the next ICDT cycle deadline with the PODS deadline and journal timelines74 -> route to the nearest honest fit; ICDT's two cycles give you two shots a year75```7677## Decision procedure7879```text80[Consequence] who in data management cares if the theorem holds? -> real payoff or decorative?81[Claim type] expressiveness / complexity / decidability / semantics / framework82[ICDT vs PODS] both fit? -> choose by calendar, open-access LIPIcs vs PACMMOD, community pull83[Sibling check] systems+experiments -> EDBT; pure logic -> LICS/ICALP; over-long -> journal84[Verdict] ICDT regular track / PODS / EDBT / TCS venue / journal, with a one-line reason85```8687Run this before the writing skills; a wrong venue decision wastes every later step. When the verdict88is ICDT, continue with `icdt-workflow` for the two-cycle calendar and `icdt-writing-style` for the89theorem-proof shape.9091---9293**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `ICDT-Skills/skills/icdt-topic-selection/SKILL.md`
thedixitjain