Since most of the things we identified were metadata around the notification messages one solution could be to add a new column to store the metadata as JSON blobs, since we are not planning to query based on metadata.

Maybe you're thinking about it differently, but to me notification expiry seems like the kind of thing we'd want to define in configuration rather than store in a DB on a per-notification basis. (One thing to bear in mind is that we'll probably want to use the same TTL, if any, for all notification types, otherwise we'll end up leaking info about the underlying notification type.)

With respect to APNS topic, is it correct that we'll only need that if we use cert-based authentication? Looking at the docs, it looks like token-based auth is preferred.

I'm thinking about this task now becuase it's a bit awkward to request final DBA signoff for launch when there's an open task called "finalize DB schema..."

Updated the task title/description per real-time discussion. Feel feel free to edit further if you'd like!

Change 607047 had a related patch set uploaded (by Jgiannelos; owner: Jgiannelos):
[mediawiki/extensions/Echo@master] Αdd column on eps_subscription table to store subscription metadata

https://gerrit.wikimedia.org/r/607047

Change 607047 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Αdd column on eps_subscription table to store subscription metadata

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/ /607047