Heroku desaconseja esto debido a posibles problemas. Soy un novato de SQL, ¿puedes explicar el tipo de problemas que se pueden encontrar al usar diferentes bases de datos?SQLite en desarrollo, PostgreSQL en producción, ¿por qué no?
Diferentes bases de datos interpretan y se adhieren al estándar SQL de manera diferente. Si tuviera que, por ejemplo, copiar pegar algún código de SQLite a PostgreSQL, hay una gran posibilidad de que no funcione de inmediato. Si solo se trata de consultas básicas, quizás, pero cuando se trata de algo en particular, hay muy pocas posibilidades de compatibilidad completa.
Algunas bases de datos también están más actualizadas con el estándar. Es un campo de batalla similar al de los navegadores de internet. Si alguna vez has creado algunos sitios web, sabrías que la compatibilidad es un fastidio, tener que hacer que funcione para versiones anteriores e Internet Explorer. Debido a que algunas bases de datos son más antiguas que otras, y algunas incluso más antiguas que las normas, tendrían su propia forma de hacer las cosas que no pueden descartar y saltar al estándar porque perderían soporte para sus clientes más grandes existentes (este es especialmente el caso con un motor de base de datos llamado Oracle). PostgreSQL es algo así como Google Chrome, bastante alto en cumplimiento de estándares pero aún con algunas de sus pequeñas peculiaridades. SQLite es, como su nombre indica, un sistema de base de datos liviano. Podría suponer que carece de algunas de las funcionalidades más avanzadas de los estándares.
Los motores de base de datos también realizan las mismas acciones de manera diferente. Vale la pena conocer y entender una base de datos y cómo funciona (más allá del nivel de consulta) para que pueda aprovecharla al máximo.
Utilicé sqlite3 en desarrollo y postgres en producción durante un tiempo, pero recientemente cambié a postgres en todas partes.
A tener en cuenta si se utiliza tanto:
Existen diferencias entre sqlite3 y postgres que va a morder. Una cosa común que encontré es que postgres es más estricto sobre los tipos en las consultas (where :string_column => <integer> funcionará bien en sqlite y romper en postgres). Definitivamente desea un área de ensayo que use postgres si su desarrollador es sqlite y si su aplicación de producción falla debido a un error sql.
SQLite es mucho más fácil de instalar en su máquina local, y es genial ser capaz de simplemente borrar/mover archivos .sqlite en torno a su directorio db /.
taps le permite duplicar sus datos de postgres del heroku en su db sqlite local. Se vuelve mucho más lento a medida que la base de datos se hace más grande, y en unos 10s de tablas y 100K + filas, comienza a tomar más de 20 minutos para restaurar.
Usted no recibirá postgres características como iLike, las nuevas tiendas de clave/valor, búsqueda de texto completo
Debido a que usted tiene que utilizar las funciones de SQL única ampliamente compatibles, puede ser más fácil para migrar su aplicación a MySQL
¿Por qué cambié? Quería algunas funciones solo de postgres, seguía detectando errores que no fueron detectados por las pruebas, y necesitaba poder duplicar mi producción db más rápido (pg_restore tarda ~ 1 minuto frente a 20+ para los toques). Mi consejo es permanecer con sqlite en dev debido a la simplicidad, y luego cambiar cuando/si es necesario para el futuro. Cambiar de sqlite a postgres para el desarrollo es tan simple como configurar postgres: no hay complejidad adicional por esperar.
Estaba en una (similar) situación. En general, es una muy mala idea usar diferentes motores de bases de datos para producción y prueba. Existen múltiples razones
Uno debe apegarse a un motor de db, a menos que tenga una razón realmente buena. No puedo pensar en ninguno.
Por un lado, no se obtienen muchas de las características más agradables de PostgreSQL. No es que esto importe mucho si solo estás usando ActiveRecord todo el tiempo y nada más complicado. Los errores y los problemas de rendimiento pueden ser mucho más difíciles de rastrear. –
SQLite es muy idiosincrásico y, por ejemplo, no admite totalmente los tipos de datos SQL más allá del mínimo indispensable. Por ejemplo, si usa una columna decimal con un conjunto de precisión y escala, SQLite simplemente ignorará esos y hará ... algo, mientras que los valores de ronda de Postgres woll están guardando. Otra cosa es que SQLite no tiene columnas de cadena de longitud limitada. Probablemente haya muchas más diferencias que harán que los dos se comporten de manera diferente en casos de bordes impredecibles que crearán divertidos errores. – millimoose