# DEVONthink + Relational Databases

**URL:** <https://discourse.devontechnologies.com/t/devonthink-relational-databases/86683>\
**Category:** DEVONthink\
**Tags:** automation\
**Created:** [April 2, 2026, 8:36pm UTC](https://discourse.devontechnologies.com/t/devonthink-relational-databases/86683 "2026-04-02T20:36:21Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![Lydian91](https://discourse.devontechnologies.com/letter_avatar_proxy/v4/letter/l/57b2e6/32.png) [@Lydian91](https://discourse.devontechnologies.com/u/Lydian91)\
**Post date:** [April 3, 2026, 2:04am UTC](https://discourse.devontechnologies.com/t/devonthink-relational-databases/86683/3 "2026-04-03T02:04:11Z")

</div>

Sure, here’s a more detailed breakdown. I have four DEVONthink databases. I’ve landed on these as a compromise between content category, file size (syncing), and unique words. You’ll have to forgive some of my cryptic naming. “Maps” is essentially my word for the “Resources” branch of PARA.

- **Artwork** (art and media—primarily PDF music scores, tables/markdown, liner notes, supplementary info)
- **Feeds** (informal “streams”—YouTube, etc.)
- **Products** (documentation and product information)
- **Publications** (formal/structured works)

 ![Maps List](https://devontech-discourse.s3.dualstack.us-east-1.amazonaws.com/uploads/original/3X/0/7/079f393835efccfb5a9af6a7938f6fb877ddcc93.png)

The root level groups in each DEVONthink database each have a corresponding “subcollection” (nested databases) in Collections. Records within a subcollection often point to a DEVONthink subgroup below these root level items. The group URL field contains the UID link to the Collections record. As you’ll see in the “Applications” example below, everything gets a record in Collections, but it only gets a parallel group in DEVONthink if there are files that need storing (in this case, just Carbon Copy Cloner).

 ![Applications Collections](https://devontech-discourse.s3.dualstack.us-east-1.amazonaws.com/uploads/original/3X/b/1/b1c43aaf21b34beab5ca0470db2411d324a26587.jpeg) ![Applications DEVONthink](https://devontech-discourse.s3.dualstack.us-east-1.amazonaws.com/uploads/original/3X/7/c/7c5759e384118729d0ad35a578a9d1aff4e72c07.png)

 ![Introduction et Allegro Collections](https://devontech-discourse.s3.dualstack.us-east-1.amazonaws.com/uploads/original/3X/2/9/2973fb79c42c6c965a996847063eb8bd5ccf2773.jpeg)

 ![Introduction et Allegro DEVONthink](https://devontech-discourse.s3.dualstack.us-east-1.amazonaws.com/uploads/original/3X/9/3/936cdabf9ff1d59faae1fe551b1ae9fd2441274b.jpeg)

 ![Introduction et Allegro DEVONthink 2](https://devontech-discourse.s3.dualstack.us-east-1.amazonaws.com/uploads/original/3X/9/6/968191100d4325226c010263c96b99f1f2b60ad5.jpeg)

Collections also has some exclusive databases (i.e. no parallel DEVONthink groups). Things like People, Groups (bands, companies, organizations), Topics, etc. These are relational fields that help to aggregate resources and build meaningful connections. This way I can browse by people or topics and quickly see all relevant resources (which are often spread across multiple DEVONthink databases). A single person could be associated with items located in multiple places.

 ![Screenshot 2026-04-02 at 6.43.29 PM](https://devontech-discourse.s3.dualstack.us-east-1.amazonaws.com/uploads/original/3X/1/6/16d3cd59df84ffac409725388372e913f2734e83.jpeg)

I’ve basically tried to atomize these data types into their most basic forms (articles, books, people, topics, etc.) so I can dynamically patch them like a switchboard operator.

---

_[View the full topic](https://discourse.devontechnologies.com/t/devonthink-relational-databases/86683)._