Hi Scott, Recently I've written backends for CockroachDB and Cloud Spanner. Perhaps those databases aren't as different as Snowflake, but I didn't have any major obstacles. I've had good success at contributing database backend API changes to Django to make future maintenance of those backends easier. It sounds like you might like to do the same.
Based on past discussions, I don't expect any more backends will be included in Django soon, nor did I expect any of the backends in core will be removed. That would only increase the maintenance burden since it would require coordinating changes across several repositories. Third party backends have to "catch up" to database API changes and new features at their convenience, but Django's development would be slowed if contributors had to be proficient in every database under the sun that has a backend for Django. You can read past threads in the mailing list for more discussions: Removing Oracle from Django core in 3.0 https://groups.google.com/g/django-developers/c/dg8BUVHKOo4 Moving database backends out of the core https://groups.google.com/g/django-developers/c/O-g06EM6XMM On Friday, January 22, 2021 at 5:34:14 PM UTC-5 foug...@apps.disney.com wrote: > Snowflake (at this point) isn't as fast as PostgreSQL for smaller > transactions. PostgreSQL couldn't handle the performance we needed to > drive our apps and we really didn't want to support a hybrid db app. We > give up a little speed for the convenience of having everything in one > system. At a recent Snowflake event, they stated that 30% of their users > were using Snowflake for application backends. They are also working to > improve their execution time on smaller transactions. > > Honestly, I don't think we'd release this as a third party package. We > have had to code around a lot of core db specific code to get Snow SQL to > work. If there was a hard API for DB backends my response would be > different. It would only make sense for us if this backend were part of > standard Django testing and support consideration. > > "Merging the backend straight to core would impose the requirement that > all changes to Django core consider Snowflake" > That's what has made the process harder than it should be to support a > non-core db. It creates second class system support in favor of the core > dbs that are code and tested against. Remove all of the db backends and > make them all third party and you'd see a lot more db support. > > Scott > > On Friday, January 22, 2021 at 5:22:24 PM UTC-5 Adam Johnson wrote: > >> Yes we would favour a third party backend. Merging the backend straight >> to core would impose the requirement that all changes to Django core >> consider Snowflake, which is a fairly steep cost when there's only one >> organization using it (at current). If you release as a third party package >> and show some adoption, it could then be argued that it's worth merging. >> >> Additionally Scott - would love to see Disney appear on this page, >> perhaps the "Platinum" section would feel comfortable: >> https://www.djangoproject.com/fundraising/ ;) >> >> On Fri, 22 Jan 2021 at 21:57, Tom Forbes <t...@tomforb.es> wrote: >> >>> I think this should definitely be released as a third party package, and >>> if there is enough community interest it might be considered for inclusion. >>> We could definitely update the docs to link to the package though. >>> >>> On a side note, is Snowflake fast enough for general purpose web apps? >>> When we evaluated it the performance characteristics where similar to >>> Redshift, optimised for large analytical aggregation rather than fast, >>> smaller result sets typically seen with Django apps. >>> >>> Tom >>> >>> On 22 Jan 2021, at 21:49, Scott Fought <foug...@apps.disney.com> wrote: >>> >>> >>> >>> We have written a Snowflake DB backend that we use internally in several >>> projects and are considering releasing it for public use. My preference >>> would be to incorporate it as a core backend so the nuances of Snowflake >>> SQL are considered when changes are made to the core system. Is this >>> something we should pursue? >>> >>> >>> Thanks, >>> >>> >>> Scott >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers (Contributions to Django itself)" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-develop...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/3e5034a8-6c75-4f28-9830-2c87b671ae86n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-developers/3e5034a8-6c75-4f28-9830-2c87b671ae86n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers (Contributions to Django itself)" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-develop...@googlegroups.com. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/08448193-19F7-4AA8-A112-ED6802DC7FBF%40tomforb.es >>> >>> <https://groups.google.com/d/msgid/django-developers/08448193-19F7-4AA8-A112-ED6802DC7FBF%40tomforb.es?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> Adam >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d5bbcbbc-32cd-4be2-967e-daafd836e887n%40googlegroups.com.
